# Certificates 101 **URL:** \ **Category:** Help\ **Created:** [May 13, 2023, 3:21pm UTC](https://community.letsencrypt.org/t/certificates-101/198242 "2023-05-13T15:21:53Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [May 13, 2023, 3:21pm UTC](https://community.letsencrypt.org/t/certificates-101/198242/1 "2023-05-13T15:21:53Z")
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](https://en.m.wikipedia.org/wiki/Privacy-Enhanced_Mail) format. The "header" and "footer" lines are called the "armor". The seemingly-encrypted gobbledygook inside the armor isn't actually encrypted; it's [Base64](https://en.m.wikipedia.org/wiki/Base64)-encoded [ASN.1](https://en.m.wikipedia.org/wiki/Abstract_Syntax_Notation_One) in [DER](https://en.m.wikipedia.org/wiki/X.690#DER_encoding) format. > **[A Warm Welcome to ASN.1 and DER](https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der/)** > > This document provides a gentle introduction to the data structures and formats that define the certificates used in HTTPS. It should be accessible to anyone with a little bit of computer science experience and a bit of familiarity with... # Certificate Chains For an RSA certificate chain, Let's Encrypt provides these certificates in the following order: 1. Your leaf (aka subscriber) certificate 2. [Let's Encrypt's R3 intermediate certificate](https://letsencrypt.org/certs/lets-encrypt-r3.pem) 3. [Let's Encrypt's ISRG Root X1 root certificate](https://letsencrypt.org/certs/isrg-root-x1-cross-signed.pem) signed by [IdenTrust's DST Root CA X3 root certificate](https://letsencrypt.org/certs/trustid-x3-root.pem.txt) 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: - [Let's Encrypt's ISRG Root X1 root certificate](https://letsencrypt.org/certs/isrgrootx1.pem) - [IdenTrust's DST Root CA X3 root certificate](https://letsencrypt.org/certs/trustid-x3-root.pem.txt) (still works on Android even though expired) For an ECDSA certificate chain, Let's Encrypt provides these certificates in the following order: 1. Your leaf (aka subscriber) certificate 2. [Let's Encrypt's E1 intermediate certificate](https://letsencrypt.org/certs/lets-encrypt-e1.pem) 3. [Let's Encrypt's ISRG Root X2 root certificate](https://letsencrypt.org/certs/isrg-root-x2-cross-signed.pem) signed by [Let's Encrypt's ISRG Root X1 root certificate](https://letsencrypt.org/certs/isrgrootx1.pem) 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: - [Let's Encrypt's ISRG Root X2 root certificate](https://letsencrypt.org/certs/isrg-root-x2.pem) - [Let's Encrypt's ISRG Root X1 root certificate](https://letsencrypt.org/certs/isrgrootx1.pem) > **[Chains of Trust](https://letsencrypt.org/certificates/)** > > This page describes all of the current and relevant historical Certification Authorities operated by Let’s Encrypt. Note that a CA is most correctly thought of as a key and a name: any given CA may be represented by multiple certificates which all... # Certificate Transparency 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](https://letsencrypt.org/docs/ct-logs/): > **[crt.sh | Certificate Search](https://crt.sh/)** > > Free CT Log Certificate Search Tool from Sectigo (formerly Comodo CA) # Certificate Decoding Should you wish to view the information contained in any certificate, you can use the following tool: > **[Free CSR & SSL Certificate Decoder | Red Kestrel](https://redkestrel.co.uk/tools/decoder)** > > Instantly decode and inspect SSL certificates, CSRs, CRLs,PKCS#7 objects, SPKI keys, Kubernetes-style certificates, and more. View subject, issuer, fingerprints, and key details with our free online certificate decoder. # Certificate Inspection Should you wish to inspect the certificate service of a website, you can use the following tool (where port 443 is HTTPS): > **[SSL Checker](https://decoder.link/)** > > Verify that your SSL certificate is installed correctly, identify installation issues if any. ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [May 13, 2023, 3:43pm UTC](https://community.letsencrypt.org/t/certificates-101/198242/2 "2023-05-13T15:43:40Z")
> [@griffin](#): > > For an ECDSA certificate chain, Let's Encrypt provides these certificates in the following order: > > 1. Your leaf (aka subscriber) certificate > 2. [Let's Encrypt's E1 intermediate certificate](https://letsencrypt.org/certs/lets-encrypt-e1.pem) signed by [Let's Encrypt's ISRG Root X2 root certificate](https://letsencrypt.org/certs/isrg-root-x2.pem) > > To communicate successfully, a client connecting to a server serving Let's Encrypt's ECDSA chain must have the following certificate installed in its trust store: > > - [Let's Encrypt's ISRG Root X2 root certificate](https://letsencrypt.org/certs/isrg-root-x2.pem) Depending on your ACME clients settings of course, I believe that Let's Encrypt by default does NOT send an entire ECDSA chain however: ```nohighlight Certificate chain 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](https://crt.sh/?Identity=%25&iCAID=183283) using crt.sh) ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [May 13, 2023, 3:45pm UTC](https://community.letsencrypt.org/t/certificates-101/198242/3 "2023-05-13T15:45:32Z")
The ECDSA chain I posted is the default one provided, I believe, but I'm glad you've provided the fullest ECDSA chain. πŸ™‚ ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [May 13, 2023, 3:46pm UTC](https://community.letsencrypt.org/t/certificates-101/198242/4 "2023-05-13T15:46:57Z")
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? ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [May 13, 2023, 3:47pm UTC](https://community.letsencrypt.org/t/certificates-101/198242/5 "2023-05-13T15:47:22Z")
I could be mistaken. πŸ€” I'll correct accordingly. ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [May 13, 2023, 3:56pm UTC](https://community.letsencrypt.org/t/certificates-101/198242/6 "2023-05-13T15:56:54Z")
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. ---
**Author:** ![Nummer378](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/nummer378/32/49862_2.png) [@Nummer378](https://community.letsencrypt.org/u/Nummer378)\ **Post date:** [May 13, 2023, 4:28pm UTC](https://community.letsencrypt.org/t/certificates-101/198242/7 "2023-05-13T16:28:12Z")
> [@Osiris](#): > > 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? 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](http://ecdsa-test.germancoding.com). You can check an ACME order to verify: [https://acme-v02.api.letsencrypt.org/acme/cert/034d2e3fa2752576acade49ca79b7ca5625c](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. ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [May 13, 2023, 4:30pm UTC](https://community.letsencrypt.org/t/certificates-101/198242/8 "2023-05-13T16:30:42Z")
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.. ---
**Author:** ![Nummer378](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/nummer378/32/49862_2.png) [@Nummer378](https://community.letsencrypt.org/u/Nummer378)\ **Post date:** [May 13, 2023, 4:33pm UTC](https://community.letsencrypt.org/t/certificates-101/198242/9 "2023-05-13T16:33:12Z")
It has been this way since E1 was introduced. You can also check my older certs: [04e1bd925fd8f0a584f25f8015f3481bcca3](https://acme-v02.api.letsencrypt.org/acme/cert/04e1bd925fd8f0a584f25f8015f3481bcca3) (issued 2023-04-03) sends the exact same chain. ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [May 13, 2023, 4:36pm UTC](https://community.letsencrypt.org/t/certificates-101/198242/10 "2023-05-13T16:36:30Z")
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 πŸ˜› ---
**Author:** ![Nummer378](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/nummer378/32/49862_2.png) [@Nummer378](https://community.letsencrypt.org/u/Nummer378)\ **Post date:** [May 13, 2023, 4:40pm UTC](https://community.letsencrypt.org/t/certificates-101/198242/11 "2023-05-13T16:40:53Z")
> [@Osiris](#): > > Hmm, OK, strange then that my "random" sites _do_ provide the cross-signed X1: 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. ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [May 13, 2023, 4:46pm UTC](https://community.letsencrypt.org/t/certificates-101/198242/12 "2023-05-13T16:46:32Z")
Meh, and I was thinking my random sample would do the trick πŸ€ͺ ---
**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\ **Post date:** [May 14, 2023, 2:13am UTC](https://community.letsencrypt.org/t/certificates-101/198242/13 "2023-05-14T02:13:42Z")
> [@griffin](#): > > The information and tools that follow are enough to bring anyone up to nearly an expert level when it comes to certificates. 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). ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [May 14, 2023, 2:17am UTC](https://community.letsencrypt.org/t/certificates-101/198242/14 "2023-05-14T02:17:50Z")
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. ---
**Author:** ![Bruce5051](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bruce5051/32/76576_2.png) [@Bruce5051](https://community.letsencrypt.org/u/Bruce5051)\ **Post date:** [May 15, 2023, 3:17pm UTC](https://community.letsencrypt.org/t/certificates-101/198242/15 "2023-05-15T15:17:44Z")
How about for [Domain Validation (DV) certificates](https://letsencrypt.org/docs/faq/#what-services-does-let-s-encrypt-offer) first step is to get a Domain Name. ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [June 14, 2023, 3:17pm UTC](https://community.letsencrypt.org/t/certificates-101/198242/16 "2023-06-14T15:17:56Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.