You can also follow the Authority Information Access url in each certificate.
4 Likes
This is supposed to be the job of the ACME client...which is to say the process is defined by the ACME protocol (specifically section 7.4.2).
To download the issued certificate, the client simply sends a POST- as-GET request to the certificate URL.
The default format of the certificate is application/pem-certificate- chain (see Section 9).
The server MAY provide one or more link relation header fields [RFC8288] with relation "alternate". Each such field SHOULD express an alternative certificate chain starting with the same end-entity certificate. This can be used to express paths to various trust anchors. Clients can fetch these alternates and use their own heuristics to decide which is optimal.
The certificate and the intermediate(s) are both provided when the client downloads the finalized certificate. If an alternate chain is available, the client is notified via the response headers for the cert download and can then download the alternate(s) as well. Most of the popular clients now support some method of specifying which chain you want to use.
Obviously, the chain details are public and Let's Encrypt provides alternative means to get them as @griffin pointed out. But if you can work with your ACME client to use the ones provided by the ACME server, you won't have to worry about updating them manually later.
6 Likes
This is where I'm confused, the ISRG Root X1 certificate sent by the server (which has been delivered by Let's Encrypt) is not a ROOT certificate AFAIK as he is not self-signed (signed by DST Root CA X3).
Command used on the ISRG Root X1 certificate retrieved from community.letsencrypt.org :
$ openssl x509 -noout -in /tmp/sent -subject -hash -issuer -issuer_hash
subject=C = US, O = Internet Security Research Group, CN = ISRG Root X1
4042bcee
issuer=O = Digital Signature Trust Co., CN = DST Root CA X3
2e5ac55d
Command used on the actual self-signed ISRG Root X1 certificate :
$ openssl x509 -noout -in /etc/ssl/certs/ISRG_Root_X1.pem -subject -hash -issuer -issuer_hash
subject=C = US, O = Internet Security Research Group, CN = ISRG Root X1
4042bcee
issuer=C = US, O = Internet Security Research Group, CN = ISRG Root X1
4042bcee
So, according to my understanding, the self-signed certificate is a ROOT certificate, but how could I determine that the ISRG Root X1 certificate sent by the server can be considered as root too ?
From a openssl point of view there is no hint right ?
The only way would be to reproduce what the browsers does: creating the alternate chain inside the probe algorithm ?
Thanks a lot for your answer 
5 Likes
You're correct.
You've misinterpreted the OpenSSL output I'm afraid. As @arulibao already said, the ISRG Root X1 certificate in the example you've quoted is NOT a root certificate, as it's indeed not self-signed. It's signed by DST Root CA X3.
That said, there is a certificate with the ISRG Root X1 private key which is self-signed. Same Common Name, same private key (corresponding with the Common Name), but a different certificate altogether.
If the issuer and subject is the same, it's an indication it's a self-signed certificate. Strictly speaking you'd need to verify the signature of the certificate with the public key of the same certificate.
However, root certificates shouldn't be visible in the chain send by the server. So it's probably better to turn it around: if the issuer and subject are NOT the same, you're NOT dealing with a root certificate.
5 Likes
This isn't entirely correct and there seem to be some misconceptions here about what a root certificate actually is:
A root certificate is something that is in your trust store. It is not something send by the server.
You're both focusing on the fact that the server sends an apparent intermediate certificate called ISRG Root X1. But ISRG Root X1 is a known root and therefore it really doesn't matter what was send by that server - it's irrelevant. A server sending some certificate doesn't change the definition of what a root certificate is. ISRG Root X1 is a root certificate and this fact doesn't change by someone sending a version of ISRG Root X1 that appears like an intermediate. The purpose of this certificate is to aid clients that are not aware of the fact that ISRG Root X1 is a root and thus show those clients an alternate path to a different root.
The hint is the trust store. OpenSSL walks up the certificate chain by first looking at the leaf cert, seeing the issuer R3, which it doesn't know, but learns it because it was send by server. Then the issuer of R3 is looked up, which is in the trust store hence the trust anchor is reached and verification is stopped*. ISRG Root X1 signed by DST Root CA X3 is never used in the verification by OpenSSL versions with X509_V_FLAG_TRUSTED_FIRST **.
I have not. The verify output above the chain displays the verification path as OpenSSL walked the tree. DST Root CA X3 (and it's "intermediate, ISRG Root X1 signed by DST Root CA X3" is not part of the verification and this is shown (or not shown, as it's missing from the verify path).
You can compare this with older versions which do not support X509_V_FLAG_TRUSTED_FIRST and sadly also misunderstand the concepts of roots:
# openssl version
OpenSSL 1.0.1j 15 Oct 2014
CONNECTED(00000003)
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = community.letsencrypt.org
verify return:1
---
Certificate chain
0 s:/CN=community.letsencrypt.org
i:/C=US/O=Let's Encrypt/CN=R3
1 s:/C=US/O=Let's Encrypt/CN=R3
i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
This OpenSSL version verifies up to DST Root CA X3, even with ISRG Root X1 in the trust store and this is shown in the above verify output. Newer versions always stop at ISRG Root X1, which can be seen from the verify output - it's unrelated to what chain you send.
**Assuming the trust store is up to date.
*This is simplified for better understanding and is in reality slightly more complicated. OpenSSL in fact first reads the chain as send by the server and then replaces certificates with the ones found in the trust store. Then signatures are verified.
8 Likes
Web browsers use a variety of strategies. One option is called AIA Chasing. The idea here is, a certificate, such as the leaf certificate for your server, has a section named Authority Information Access which indicates a URL where there's a certificate for the issuing CA. This certificate of course might in turn contain AIA. This has a small privacy impact, because during AIA chasing the CA learns that you enquired about some certificate it issued, and in theory they could set AIA to indicate separately each such certificate issued (Let's Encrypt of course does not) so that they could track exactly which sites are visited.
Another option is to remember intermediate CAs the browser encountered recently and use those to try to "fill in the gaps" when visiting a site that doesn't provide a chain. Because certificates are signed documents, it isn't important where you saw them, you know they're authentic, but this can mean sites work OK on a "warm" browser but don't work if visited from a new session or e.g. after rebooting.
Current Firefox versions provide a complete set of all unconstrained intermediates (e.g. R3) baked in the browser itself, so it will work with any normal public certificate even if your server didn't send the chain correctly.
Of course you should not depend on this in your site as doing so can only make it less reliable, and software other than web browsers rarely implements these strategies.
6 Likes
Hm, my bad, I assumed (incorrectly) that the root certificate used as trust anchor didn't show up in the verification list of certificates of the OpenSSL output. So I assumed that when it showed and stopped at the ISRG Root X1, it showed it as an intermediate certificate.
By the way, I'm not entirely sure if the definition of a root you're using here is also globally used. I've heard about trust stores assigning trust to just the private key instead of a (self signed) certificate, but if all trust stores work that way? I dunno..
5 Likes
I would argue that it's technically the public key, as you can't trust something you don't know. But yeah I see what you mean - definitions can vary.
A fact is that you need to name your keypairs - which is what the certificates commonly do (by having a Subject field). You can also use things like the Authority Key Identifier to identify things. For example, you can have a singular issuer with multiple keys - PKI can get really complicated and getting everything right is really difficult - as seen by the dozen implementations getting it wrong.
From my trips to the source code, I believe OpenSSL to be mostly certificate based.
Also interesting thought: Most modern implementations allow you to put not self signed certificates (e.g intermediates) in the trust store and assign trust to them [even if the actual issuer is unknown and untrusted] - does this make them roots or intermediates? 
4 Likes
Well, public/private keypair is probably the correct term, as one can't exist without the other in RSA/ECDSA (and probably for EdDSA too?). I mean, they are mathematically bound to each other.
True, the Subject is referring to the keypair indeed, as per RFC 5280:
The subject field identifies the entity associated with the public key stored in the subject public key field.
Assuming the "entity" referred there is the keypair.
IMO roots, as they can be used as an anchor for a trusted certificate chain. And makes sense if we agree a trust anchor is an entity (i.e.: keypair) and not the certificate itself. So who cares who signed the cert 
3 Likes
They would be "Trust Anchors". They might also be "Subordinate CA Certificates", depending on if they chain up to a "Root CA Certificate". The following definitions are taken directly from the current version of the Baseline Requirements (v1.8.0):
- Certification Authority : An organization that is responsible for the creation, issuance, revocation, and management of Certificates. The term applies equally to both Roots CAs and Subordinate CAs.
- Root CA : The top level Certification Authority whose Root Certificate is distributed by Application Software Suppliers and that issues Subordinate CA Certificates.
- Root Certificate : The self-signed Certificate issued by the Root CA to identify itself and to facilitate verification of Certificates issued to its Subordinate CAs.
- Subordinate CA : A Certification Authority whose Certificate is signed by the Root CA, or another Subordinate CA.
People often think of the Web PKI as a graph whose nodes are certificates and whose edges are trust relationships between those certificates. This is inaccurate. The Web PKI is a graph whose nodes are public/private keypairs, and whose edges are certificates. Root programs, or trust stores, trust nodes (keypairs) in that graph, not edges (certificates). The fact that trust anchors are represented by (usually self-signed) certificates is mostly just because certificates are a handy format to carry around a public key and various metadata about that key.
10 Likes
If anyone wants a visual of that for ISRG Root X1, we can look to crt.sh...
ISRG Root X1 (signed by DST Root CA X3):
3 Likes
So for this expiring root cert that is coming up end of September we have an automation that currently brings down a new wildcart cert for our domain every Sunday to give us a fresh 90 day cert however I noticed that in the full chain the root and intermediate are still showing the expiring certs 9/29 and 9/30. Do we need to do anything to have it pull down the newer root/intermediate certs or will it pull those down closer to expiration? Sorry for the "dumb" question i'm a bit of a LE noob.
1 Like
@smittysays88 I'm pretty sure your question is related to the question in your other thread When will the Root/Intermediate Certs be available Maybe it's useful to continue there? Also, I've pretty much answered (part of) your question there already.
Oh, I'm just seeing now @jillian actually moved your post from a second thread of yours into this current thread.. Although I believe I've answered your question in your first thread I linked above already.
4 Likes
Yes you answered the other thread but this is a different question.
1 Like
I respectfully disagree. In your current question you're asking if you need to do anything to use the newer root/intermediate certificates instead of the ones almost expiring. In your previous thread, you mainly asked about when the new certs would be available. However, in your previous thread I already tried to explain that properly configured ACME clients should already have been using the new certs since May this year. So essentially I already answered your current question in your previous thread, as the answer to your current question is: yes, YES you should do something to start using the new certificates, as your current setup is NOT how it's supposed to be setup. In your previous thread I also already answered that it's ACME client dependend on how to achieve that.
So that's why I'd recommend continuing in your previous thread, as your current question is, IMO, highly related.
4 Likes
Hi,
When does this transition change ? I re-issued my Certs but the old new Cert is still showing the old date under R3 and DST Root CA X3 section in Firefox although pfSense shows that its updated under the CA Section, Im using Acme.
2 Likes
Clear your browser cache.
3 Likes
Hi,
I have done but still doing showing the same but the website you linked shows Common Name: R3 Sep 04, 2020 00:00:00 GMT to Sep 15, 2025 16:00:00 GMT
Common Name: ISRG Root X1 Jan 20, 2021 19:14:03 GMT to Sep 30, 2024 18:14:03 GMT
But the browser shows different still. So theres nothing wrong with the Certs?
2 Likes
Current default RSA chain:
Current alternate RSA chain:
Old default RSA chain:
3 Likes
