Ok so Let's Encrypt is not a root CA? From the post it seems it is an intermediate CA that would be verified by verifying there chain up until the root CA. But I have Let's Encrypt CA certificate installed in my operating system. And so I am still confused what's a root CA and what's an intermediate one.
Remember, "root" and "intermediate" are terms that apply to certificates, not organizations. Let's Encrypt does operate two root certificates which you can see installed in your OS/browser. They also operate several intermediate certificates (which were issued by their root certificates), since CAs are not allowed to issue website certificates directly from roots.
Root and intermediate certificates are both able to issue further certificates; the difference is that roots are installed directly in your OS/browser.
Let's Encrypt is kinda both. They originally operated under an intermediate signed by another CA, which they still do, though in a kinda hacky way (the root they originally were signed under is expired). But they also have their own root by now.
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.)
Yes, right. It's ISRG root certificate that's present in my OS certificate store. I was trying to troubleshoot our new web server where we have set up a let's encrypt certificate but some clients report issues. SSL lab test identifies the problem as missing intermediate certificate. Chrome doesn't have any problem accessing the HTTPS URL though. The problem I was trying to fix is my Go code that refuses to access this URL stating it can not validate the certificate. Sorry I am on mobile so can't give exact details.
This was a timely article but still left me confused.
The web server should be configured to send the entire chain, not just its leaf certificate. Missing intermediate certs is a common cause of such issues.
Really, you shouldn't send the entire chain. Just the leaf and intermediates (and maybe a cross signed root). There's no need to send the root certificate --- if the client trusts your root, it already has it; if the client doesn't trust your root, sending it doesn't help.
On top of this: sending the entire chain makes it much easier for the client to do silly and insecure things, like naively trusting any root the server presents (meaning that the connection would effectively be self-signed, rather than chained to a pre-trusted CA).
Right, the whole chain back to (but not including) the root. Every intermediate must be sent if you want maximum compatibility, roots should never be sent by anything other than an application or OS update.
Thanks. But this is where my confusion is. I am wondering whether the certificate installed on the web server was signed by Let's Encrypt root or some intermediary (may be another let's encrypt entity). It was issued and installed using standard let's encrypt tooling for Ubuntu.
It was signed by a Let's Encrypt intermediate. Roots are not allowed to sign website certificates.
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).
Andrew misunderstands the purpose of including CloudFlare in the cert. He thinks its to easily identify the CA. The ICA is not used that way. In this case, Cloudflare is the one managing all of the certificates issued off this change. If you have an issue with the certs, you know Cloudflare is the one managing it.
He says “its completely useless for human consumption”, but that’s just more of the same misunderstanding. Afterall, would you rather know that all the sites are being operated by Cloudflare or know that DigiCert issued the cert? The average person doesn’t care who issued the cert – they care about who is managing the certs.
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.
This was a good article. Slightly related, because it was linked in the article, I am interested in the Cert Spotter service, but the lack of disclosure of pricing is an immediate deal breaker for me. It's odd, they're upfront about their pricing for their other services; for Cert Spotter, it seems to be hidden behind a 30-day trial. I'm not going to try something I have no idea what the long term costs will look like.
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.
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.
Thank you, that's excellent feedback! I'm going to go ahead and add the pricing to the product page as you suggest; I hadn't even realized that this was inconsistent with the other product pages.
Decrypting implies a message sent to the real owner of the domain (using their public key) being intercepted and decoded. If that's the case then no, once you have encrypted a message with a public key (or more realistically exchanged a symmetric key using the public key) that message is as safe as it can be
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
Nope, but you could intercept the traffic to their IP then use Letsencrypt to generate a bunch of new certs on their domains, as only thin needed to validate non-wildcard certs are few http requests to a given IP that domain points to
By having an already trusted CA cert on the client. But that would involve a really elaborate attack by an APT (having for instance a stolen CA that's still valid).
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.
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.)
(I want to second the thanks for the excellent blog post!)
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.
From a policy standpoint, including AKI will still be a MUST, as will SKIs in CA certificates. Only in end-entity certificates will SKI be NOT RECOMMENDED.
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.
Chrome and Safari only accept certificates which are publicly logged in Certificate Transparency logs, so if a government actor uses a CA to issue malicious certificates, they run a high risk of being detected and having that CA distrusted.
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.
Compromising a CA doesn’t “get” you anything in the web PKI scheme: holding the CA’s private key doesn’t get you access to individual end entity keys, and issuing a new certificate with it loudly announces your presence due to CT.
Intelligence agencies are, in all likelihood, far more interested in obtaining individual end entity keys than they are in CAs.
Even the end entity keys are rarely interesting. Increasingly they are signature keys, and so the only thing you can use those keys for is impersonation, which is cumbersome. What you want more often are session keys so that you can either listen in live (if you obtain in time) or decrypt a transcript later if you don't. Because this is passive it's harder to detect and easier to deny.
