3 ms·
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 C
by ssd532 3y ago
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.
- agwa 3y agoRemember, "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.
- hannob 3y agoLet'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.)
- ssd532 3y agoYes, 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.
- SAI_Peregrinus 3y agoThe 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.
- ssd532 3y agoThanks. 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.
- agwa 3y agoIt 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.
- ssd532 3y agoAh, got it now. Thanks.
- tialaramex 3y ago[Andrew knows this but for the benefit of others] 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).