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.
For an RSA certificate chain, Let's Encrypt provides these certificates in the following order:
- Your leaf (aka subscriber) certificate
- Let's Encrypt's R3 intermediate certificate
Let's Encrypt's ISRG Root X1 root certificate signed by IdenTrust's DST Root CA X3 root certificate
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:
For an ECDSA certificate chain, Let's Encrypt provides these certificates in the following order:
- Your leaf (aka subscriber) certificate
- Let's Encrypt's E1 intermediate certificate
Let's Encrypt's ISRG Root X2 root certificate signed by Let's Encrypt's ISRG Root X1 root certificate
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:
Should you wish to view the information contained in any certificate, you can use the following tool:
Should you wish to inspect the certificate service of a website, you can use the following tool (where port 443 is HTTPS):
Depending on your ACME clients settings of course, I believe that Let's Encrypt by default does NOT send an entire ECDSA chain however:
0 s:CN = idatjamneemorapp.ml
i:C = US, O = Let's Encrypt, CN = E1
1 s:C = US, O = Let's Encrypt, CN = E1
i:C = US, O = Internet Security Research Group, CN = ISRG Root X2
2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X2
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
3 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
i:O = Digital Signature Trust Co., CN = DST Root CA X3
(Random website with cert signed by E1 using crt.sh)
The ECDSA chain I posted is the default one provided, I believe, but I'm glad you've provided the fullest ECDSA chain.
Are you sure? The second host of the list also sends the long chain.
The last one of the first page also. What are the chances three "random" hosts all have the non-default chain set up?
I could be mistaken.
I'll correct accordingly.
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.
My personal test site for E1 certs is ecdsa-test.germancoding.com. You can check an ACME order to verify: https://acme-v02.api.letsencrypt.org/acme/cert/034d2e3fa2752576acade49ca79b7ca5625c (the cert currently served on the link above). There are no alternate chains being offered (there is no rel-alternate link) and the chain send by the ACME server only includes 3 certificates, including the leaf.
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..
It has been this way since E1 was introduced. You can also check my older certs:
04e1bd925fd8f0a584f25f8015f3481bcca3 (issued 2023-04-03) sends the exact same chain.
Hmm, OK, strange then that my "random" sites do provide the cross-signed X1:
openssl s_client -connect idatjamneemorapp.ml:443
openssl s_client -connect villapandora.gr:443
openssl s_client -connect ldsports20.com:443
Maybe part of a series of certs from a single integrator with non-default chain?
Ah well, I guess @griffin can just edit the chain again, this time the one not already used
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.
Meh, and I was thinking my random sample would do the trick
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.
How about for Domain Validation (DV) certificates first step is to get a Domain Name.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.