What follows is a self-guided study of certificate fundamentals that provides a deep and solid foundation of knowledge regarding these things we call certificates. The information and tools that follow are enough to bring anyone up to nearly an expert level when it comes to certificates. Please don't feel that you need to absorb it all.
ASN.1 and DER
When you look at a certificate issued by Let's Encrypt, your initial impression might be that it's a collection of encrypted gobbledygook encased within header and footer lines. If you look closer, you'll realize that there are actually multiple certificates in sequence. Each of those is in PEM format. The "header" and "footer" lines are called the "armor". The seemingly-encrypted gobbledygook inside the armor isn't actually encrypted; it's Base64-encoded ASN.1 in DER format.
Certificate Chains
For an RSA certificate chain, Let's Encrypt provides these certificates in the following order:
To communicate successfully, a client connecting to a server serving that RSA certificate chain must have at least one of the following certificates installed in its trust store:
To communicate successfully, a client connecting to a server serving that ECDSA certificate chain must have at least one of the following certificates installed in its trust store:
Should you wish to research any certificate issued by Let's Encrypt (or most any publicly-trusted certificate authority (CA)), you can use the following tool, which aggregates certificate transparency (CT) logs:
Certificate Decoding
Should you wish to view the information contained in any certificate, you can use the following tool:
You also might want to note that the expired IdenTrust root still works on Android as I believe Android is pretty much (if not absolute, there might be other systems, but I don't know any) the only OS ignoring the NotAfter date of their root certificates.
As of 2023-05-13 (just force-renewed to get up to date data), the default E1 chain send by Let's Encrypt only includes E1 and ISRG Root X2 cross-signed. There is no DST cross sign included.
Hmm, I didn't check the date of the cert I pulled from the E1 crt.sh link, maybe crt.sh provided me with older certs? It did give me multiple 503 errors before I saw something..
Yeah, and going through the list I can find just as many that only send E1 and do not even send the ISRG Root X2 cross sign. That's also not offered by the ACME server.
I can only theorize as to why that is. Your option sounds plausible. Other options include manually crafted chains - since E1 is opt-in, people on that list are less likely to operate "autopilot"-style, so manual chains are more likely.
I would suggest adding information about the certificates themselves, including the concept of subject, issuer, subject alternative name, public key, private key, and digital signature. To me, those concepts are even more fundamental!
Maybe also the purpose of the certificate (to confirm that an issuer said, on a particular occasion, that a subject possesses a particular key—in the Internet context, that the owner or operator of a particular Internet domain name, or several of them, possesses the specified key, and so that it's legitimate for Internet services identified by that domain to authenticate themselves to visitors using that key).
Thanks for the suggestions. I'll look to expand soon once I have some more time. I'm trying to strike a balance to keep it streamlined while also being reasonably comprehensive.
