Hi Team,
We are using ISRG Root X1(common name) cert for one of our customer. It is getting expired by September 30, 2024. We are in a need to update the latest cert soon to avoid an outage.
We found a latest cert, which is valid till 2035 at - crt.sh | 9314791
Serial Number of the cert: 82:10:cf:b0:d2:40:e3:59:44:63:e0:bb:63:82:8b:00
We would like to confirm that this cert is a valid, latest of the cert with common name - 'ISRG Root X1'. Please help us by confirming.
Thanks in advance
You can find the chain of trust, including all valid root and intermediate certificates at
The ISRG Root X1 which is expiring 2024-09-30, is an already retired cross-signed certificate. It shouldn't be in use any longer to begin with.
Clarifying what Osiris said:
[Updated] The ISRG Root X1 Certificate with a "notAfter" of 2035-06-04 is considered to expire on 2030-06-04 due to root program policies. The single Certificate has a technical validity until 2035, but will expire from root programs and usage in 2030. [I apologize for the confusion on this.]
A retired version of ISRG Root X1, which was cross-signed by another trusted Root, expires on 2024-09-30.
No action should be needed. The Root Certificates are only on the Client/Browser, and not configured on the webserver.
It is possible you or your client leveraged an anti-pattern and hard-coded the certificate chain onto their website, instead of using the one automatically provided by LetsEncrypt. That is something you will need to investigate.
No clients should be referencing the cross sign as of September 6th. That is over 90 days after LetsEncrypt stopped issuing any certificates that leverage the cross-sign on June 6th.
If your client is referencing the cross-sign, then they are doing so either because they are using an ACME client that did not implement the specification and relied on an anti-pattern, OR they manually crafted the chain of trust. Both situations will require manual intervention.
The presence of the Cross Sign in your client's stack after September 6th is basically a big warning sign that somebody didn't read the instructions.
That's not a typo, but an intentional decision by Let's Encrypt to more accurately reflect the actual expected lifetime:
Thanks. ISRG already corrected me on the PR.
More precisely, this is due to CA/Root CA Lifecycles - MozillaWiki.
Hi @jvanasco,
Thanks for your response.
Could you please confirm the cert - ISRG Root X1 - "notAfter" of 2035-06-04, ( serial number:82:10:cf:b0:d2:40:e3:59:44:63:e0:bb:63:82:8b:00) is the replacement to ISRG Root X1 expiring by Sep 30, 2024 (serial number: 40:01:77:21:37:d4:e9:42:b8:ee:76:aa:3c:64:0a:b7) ?
Thanks in advance
Hi @jvanasco
We have another question, When we look at the certificate in the chain of trust page(Chains of Trust - Let's Encrypt), we see the ISRG Root X1 & ISRG Root X2. Should we be using ISRG Root X2?
Thanks
You can, but both should be in most systems' trust stores at this point.
But your questions are missing a lot of context; most people don't need to worry about root certificates at all. Are you building your own trust store for some purpose? If so, there's a lot more to consider than just using X1 or X2.
X1 is a RSA Certificate.
X2 is a ECDSA Certificate.
They have different compatibilities when it comes to Trust Stores Certificate Compatibility - Let's Encrypt
There are also differences in performance.
LetsEncrypt will automatically chain RSA certificates to X1 Root through the R{n} Intermediates, and ECDSA Certificates to X2 Root through the E{n} Intermediates.
The decision to select which root and certificate type is largely dependent upon your audience.
Of the certificates you listed above:
LetsEncrypt did not replace one root with the other, and the self-signed X1 existed before the cross-sign. The validity and utility of the cross sign for legacy support has simply ended.
While the usage of the cross-signed certificate has been replaced by only supporting the self-signed certificate, this only happens within a browser or library when computing the chain of trust. As I noted in an earlier comment, there should not be any manual configuration of a Root or Intermediate Certificate in your web services. The ACME protocol handles this automatically. If your system has a root or intermediate configured - which it must if you are asking these questions - you have almost certainly deployed an anti-pattern that must be fixed. An ACME Client may support "preferred roots" to select a root and chain, but you would configure the ACME client with that preference - you would not configure any web service to use that root. Basic web servers and nearly all web services do not require a root to be configured. There only exists an incredibly small number of software that requires configuring a Root.
This is a long way of saying: The questions you have asked indicate that you are most likely doing something wrong.
An ECDSA cert chains through those intermediates but, by default, also chains to X1 root. Your ACME Client must choose the alternate chain if it wants the X2 chain.
See Chains topic: Chains of Trust - Let's Encrypt
Partial extract from that page:
Subscriber certificates with ECDSA public keys are issued from our ECDSA intermediates, which are issued both (i.e. are cross-signed) from our RSA root ISRG Root X1 and our ECDSA root ISRG Root X2. Therefore we offer two chains for these certificates: ... The first chain, up to ISRG Root X1, provides the greatest compatibility because that root certificate is included in the most trust stores. ... We provide the first chain by default, to ensure the widest compatibility
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.