The Difference Between Root Certificate Authorities, Intermediates and Resellers
agwa.name
agwa.name
Root and intermediate certificates are both able to issue further certificates; the difference is that roots are installed directly in your OS/browser.
Though you shouldn't have a certificate called "Let's Encrypt" in your root certificate store, as it is called ISRG Root. (ISRG stands for Internet Security Research Group, and is the legal entity behind Let's Encrypt.)
This was a timely article but still left me confused.
And that's why your server needs to also send the intermediate certificate - so that clients can construct a chain of signatures from your website certificate to the root that is installed in the OS trust store.
This (the fact all end entity certificates are signed by an Intermediate, never a root) is a policy of the Web PKI rather than being inherent to any conceivable system for such a purpose or to the X.509 technology in particular.
Specifically the roots aren't allowed to be online by policy. So you can't use them to issue end entity certificates, when they do sign things (notably to create new Intermediates) that's a supervised activity, several humans (perhaps an officer from the organisation which owns the root, plus somebody representing their third party auditor, plus a technician to do the actual work) are typically physically present overseeing the signing process. The rest of the time the roots might live in a safe in somebody's office, that sort of thing.
This sort of safeguard means even catastrophic IT failures should only result in a compromised Intermediate. Still not good, but recoverable without needing to co-ordinate large numbers of third parties or greatly annoy the Relying Parties (ordinary people).
The name of the root is to indicate ubiquity, not to provide identification of the CA who is operating it. If you need to know whether a cert will work on an older platform, you look at the name of the cert embedded, not the serial number. Its faster and easier to do so. You also want to know when things will expire and when you might need to migrate CAs. That’s best done with the name of the root. Plus – this is how browsers track which roots are trusted. Browsers could tie to the serial number, but they use the subject info of the cert for identification purposes on what roots are included and what roots are audited.
In summary, he has misguided notion about why these values are in the certs and the value they provide. He sees no value in them because he assumes people will be looking at the ICA and root purely to contact the CA, when that is rarely the case. I dont think there is a security or real issue with the information.
Cert Spotter pricing is listed on https://sslmate.com/pricing/certspotter
If we could be more clear about it, please let me know. I know that "enterprise" pricing isn't listed, but that option is for customers who want to negotiate custom terms in the contract or want other special arrangements. Obviously, it's impossible to give a price until we know what they want. For customers who just want an off-the-shelf plan, our intention is to be clear with pricing.
Also state authority ouside of US.
I missed the Pricing section in the top left. I think you might be served well showing that information directly on the product page [0] or linking directly to it there. This would be especially helpful on mobile where discoverability of the menu isn't as good as on desktop since it's hidden behind a click. Your other product pages are better at showing this information.
In a BGP hijacking attack, can traffic be decrypted by somehow linking it to a new (root) CA the attacker owns?
With BGP hijacking you could intercept the traffic from the real website, but you still need a valid certificate which is signed (indirectly) by a trusted CA, meaning the attacker would need to add their root CA to the list on the user device
The victim in the paper you mention aren't users but rather the CAs themselves (though the certificates issued can then be used against users)
I am quite sure that the main sticking point remains: CA name are not what you think it is so master that concept firstly before poising any CA questions; far too many do not get this ecosystem of certificate authorities and how they come to be.
Indeed, if people take one thing away from this article, it should be that the name in CA certificates is meaningless.
If I could suggest another article subject that I think very few people are aware of and would make good hay.
How certificate SKIDs work, and why everyone can tell from the transparency logs every time you reuse your private key and every certificate ever issued to that SKID.
Not a bad idea to write a post about SKID because everyone misunderstands it! It does not reliably identify a key, since CAs are allowed to derive it however they want. If you want to find other certificates using the same key, you should ignore the SKID entirely and instead search based on the hash of the SubjectPublicKeyInfo. (In fact, starting September 15, inclusion of the SKID in website certificates will be NOT RECOMMENDED.)
Do you know if the dis-recommendation of SKIs also applies to AKIs? I know they’re similarly (but slightly less) flexible, so moving away from them would (seem) to be a win as well.
That said, they all suffer from the same problem - they look like they're derived from the public key, but there's no guarantee of this. Their only use is as an opaque identifier for looking up the issuer of a certificate, and only some certificate validators use them (e.g. Microsoft's); other validators (e.g. Mozilla's) ignore AKI/SKI entirely and just look up issuers by subject name, which works completely fine, suggesting that AKI/SKI are unnecessary.
When evidence came to light last year that Trustcor might be compromised by government actors, it was distrusted by browsers, as was Dark Matter before them. If you have any evidence that current CAs have been compromised, please provide it so they too can be distrusted.
Intelligence agencies are, in all likelihood, far more interested in obtaining individual end entity keys than they are in CAs.