What is the chain to pass to --preferred-chain argument to keep using DST Root X3 root certificate?

[rg305]

Fingers crossed - legs crossed - eyes crossed - lol

[kjb]

Does anyone know where I can find a copy of "Fake LE Root X2"?
I think it should be at http://cert.stg-root-x2.letsencrypt.org/ but that URL is dead.

[Osiris]

@_az Should they be added to https://github.com/letsencrypt/website/tree/master/static/certs ?

[_az]

I think so. I was hoping maybe that I could sneakily pull it off the Testflume log server, but only "Fake LE Intermediate X1" is there, which makes sense.

[Osiris]

@_az

which makes sense

I don't think it make sense. Why would the test CT not incorporate a root certificate (it only accepts certs chained to Fake LE Root X1) for an active root certificate for the staging server?

[_az]

Testflume, according to its get-roots, accepts certificates signed by Fake LE Intermediate X1.

Ultimately, leaf certificates that are accepted are signed by Fake LE Intermediate X1's key.

Whether the end-user chooses to use the intermediate which is signed by Fake LE Root X1 or Fake LE Root X2 doesn't matter to the log.

(Why Testflume is configured with the test intermediate rather than the test roots, I don't know ).

[Osiris]

@_az

Testflume, according to its get-roots , accepts certificates signed by Fake LE Intermediate X1 .

Oh, my mistake, I used the command from Certificate Transparency (CT) Logs - Let's Encrypt to check that too and I thought it said the root certificate and not the intermediate, but perhaps I didn't read it correctly.

Nope, read it correctly:

Edit: nevermind, read below..

[_az]

@Osiris

Nope, read it correctly:

Shouldn't we be looking at -subject instead?

If this is the list of acceptable root certificates, then surely it is the identity of the certificate itself that is important.

Edit: ah I see, you copied that command verbatim from the Let's Encrypt website. Seems that I need to re-read the Certificate Transparency doc ... but it doesn't make sense to me right now.

... Or maybe that command was written under the assumption that intermediates would never appear in get-roots and because roots are by definition self-signed, there is no difference between -subject and -issuer. .

[Osiris]

Ah, I see the issue! I C/P'd the command with minor adjustments from the CT log page indeed, but didn't think about -issuer vs. -subject..

[fzo]

Thanks everyone for your interest in this topic.
What I was meaning by "checking that this is working" was:

• Before January 11, 2021, even an incorrect chain specified to -preferred-chain arg (e.g. --preferred-chain "Innexistant CA") will be signed by DST Root CA X3

• I was looking for a way (a specific log entry or something on stdout) to check that the chain argument is correct and that "DST Root CA X3" is not used as fallback

• All of that in production environment

[jillian]

@fzo

I was looking for a way (a specific log entry or something on stdout) to check that the chain argument is correct and that "DST Root CA X3" is not used as fallback

If you want to check that the Certbot flag works as expected, one option is to spin up a small testing environment and test the flag using the 'ISRG Root X1' chain that Let's Encrypt will move to on January 11, 2021. If the test certificate correctly chains to ‘ISRG Root X1’, it should be sufficient to conclude that it will work if you set --preferred-chain "DST Root CA X3".

Another option if your certificate expires after January 11, 2021. You can renew your certificate with the --preferred-chain “DST Root CA X3” after the switchover date (possibly using the force-renewal option) and inspect that the new/renewed certificate is correct before using the cert and adding the flag to your renewal configuration. Although you’ll have to wait a few months to test and feel assured in the flag, this might be the best option. You can ensure you’ll have plenty of time to fix any problems by renewing your certificate just before the switchover date and get a certificate for 90 days where the default chain is the ‘DST Root CA X3’ then do the testing. Your plan might be something like this:

• January 1, 2021: renew/force-renew current certificate (chains by default to ‘DST Root CA X3’ for 90 days)
• January 12, 2021: renew/force-renew certificate in cert-only mode with --preferred-chain “DST Root CA X3” (check for correct chain)
• When testing is done: update Certbot renewal configuration to always specify the chain

Unfortunately this is a lot of manual, “remember this” work but once you finish testing it can be automated until ‘DST Root CA X3’ expires in September 2021. (edit: the cutover will be earlier see this post)

I think your Certbot logs should include information on the chain that you can review. Otherwise, you can use an openssl command to get the certificate chain of a cert file or look at the finer details in an ssllabs.com report for the domain (‘Certification Paths’) if your cert is being used by a web server.

Here is an example in SSL Labs of a cert that specifies the chain to ‘ISRG Root X1’ for https://valid-isrgrootx1.letsencrypt.org

[jillian]

I don't want this edit burried in the long reply.

@jillian

Unfortunately this is a lot of manual, “remember this” work but once you finish testing it can be automated until ‘DST Root CA X3’ expires in September 2021. (edit: the cutover will be earlier see this post)

The reasoning is captured in the first foot note:

@_az

[1]. Although the Identrust cross-sign will expire on September 29 2021, the Let's Encrypt ACME server will stop offering the Identrust certificate chain around 90 days before that date. This is to ensure that all installed certificate chains are valid for the full 90 day lifetime of a Let's Encrypt certificate.