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).
