Planned changes to Lets Encrypt - short chain delivery

[robertgraham12345]

On the 9th November Lets Encrypt released a changes to production by accident that caused an error in Certes.

Error Message: Can not find issuer 'C=US,O=Internet Security Research Group,CN=ISRG Root X1' for certificate 'C=US,O=Let's Encrypt,CN=R3'

They investigated and put there hands up and said a change had crept in to the release that was not meant to happen until Feb 2024. So the issue that caused the error will be released onto live server very soon.

This change involves not returning the root certificate with the request (short chain). You will need to excuse me but I'm no expert in the field but here is a link to the post explaining what happened.

https://community.letsencrypt.org/t/can-not-find-issuer-c-us-o-internet-security-research-group-cn-isrg-root-x1-for-certificate-c-us-o-lets-encrypt-cn-r3/208268/1

Here is the announcement by Lets Encrypt: https://letsencrypt.org/2023/07/10/cross-sign-expiration.html

Is there a plan to update this library to work with this change?

Thanks

Rob

[webprofusion-chrisc]

Hi Rob, just to clarify, the issuer cert ISRG Root X1 is already embedded in this version of certes and has been for about 3 yrs.

[Fashdey]

I am now getting this as well - Did you find a solution?

Unhandled exception. Certes.AcmeException: Can not find issuer 'C=US,O=Internet Security Research Group,CN=ISRG Root X1' for certificate 'C=US,O=Let's Encrypt,CN=R3'.

Failing step (based on the snippets - of course they are adjusted for my usage, as they have worked for years until a few days ago)

var privateKey = KeyFactory.NewKey(KeyAlgorithm.ES256);
var cert = await order.Generate(new CsrInfo //<--- Failing Step
{
CountryName = "CA",
State = "Ontario",
Locality = "Toronto",
Organization = "Certes",
OrganizationUnit = "Dev",
CommonName = "your.domain.name",
}, privateKey);

[cpkuo]

I'm also getting this error. How do we work around this? Thanks!

[cpkuo]

Follow up. I upgraded to version 3.0.4 from 2.3.4 and it seems to work now. @Fashdey, what version are you on?

[webprofusion-chrisc]

For anyone seeing "Can not find issuer" this means that when building the PFX file the Root certificate from the CA was not recognized. Certes currently bundles a couple of known roots and this is primarily how the process knows about the roots and v3 onwards (released 3 years ago) knows the newer ISRG Root X1 root.

If you were to try a different CA the build would fail, unless you use the AddIssuer method of PfxBuilder to populate the roots you need.

[edit: I do have a fork of Certes called Anvil (used in Certify The Web), that amongst other things and experimental features, optionally doesn't require known roots ]

[aarongable]

What changes would be necessary to remove this root bundling entirely? It seems like an easy and error-prone way for clients to get out of date (e.g. it doesn't contain ISRG Root X2, it doesn't include any other ACME CA's roots, and it does contain LE's Staging root presumably for testing but we make no guarantees that that root will remain stable) and experience breakage. It would be better for the WebPKI as a whole for Certes to use the system trust store rather than these bundles certs, but I'm sure these are here for good reason -- so what are the technical hurdles in the way of removing the need for these?

[jvanasco]

This change involves not returning the root certificate with the request (short chain). You will need to excuse me but I'm no expert in the field but here is a link to the post explaining what happened.

I need to correct the above misinterpretation:

The "Short Chain" is as follows:

• Intermediate: R3 Signed by ISRG Root X1
• [Root: ISRG Root X1 is in the client Trust Store]

The "Long Chain" is:

• Intermediate: R3 Signed by ISRG Root X1
• Intermediate: ISRG Root X1 Signed by DST Root CA X3
• [Root: DST Root CA X3 the client Trust Store]

In both situations, the certificate functioning as the "Root" is expected to be - and must be - in the client's Trust Store. As @webprofusion-chrisc notes, the X2 root has been included in an application bundle for several years now. As @aarongable notes, it is best to use the system trust store as this bundle can be out of date.

The "Long Chain" presents a version of ISRG Root X1 that is cross-signed by DST Root CA X3. While the names are similar and they use the same Private Key, the cross-signed version of X1 does not function as a root certificate here - but instead functions as an intermediate to derive trust from the DST root.

LetsEncrypt never bundles the root in the chain (a behavior supported by the ACME RFC).