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

Then the answer to:

Is to use (brute) force?
certbot renew --preferred-chain "DST Root CA X3" --force

Why would you "force" anything @rg305? The current certificate is already chaining to `DST Root CA X3".. Just renew when the time comes will do fine.

1 Like

How does that answer:

Please tell me there is a simple and logical answer.

1 Like

There is: you can't.

You can only indirectly test it by testing your client for correct handeling of the chain by testing --preferred-chain on the staging environment and making sure you've got the correct CommonName for the IdenTrust root. I.e., don't make a typo.


Yes, the more I think about it, the more it becomes clear that this is a client side implementation.
And there is no present production way to alternate the testing.
Lord help us.
So many clients ..., so many ways for this to go wrong.

1 Like

For the purposes of testing --staging --preferred-chain "Fake LE Root X2" will work, even if it's in cli.ini.

I posted the names of the chains earlier here.

The Certbot team had planned to make an announcement on how to prepare for the transition if you plan to use the legacy chain. That's what I linked 2 posts ago. I think it was supposed to come out at the same time as the Let's Encrypt post. Obviously that didn't happen and we're getting lots of posts about it now.

Ultimately you have to put some trust into the instructions it provides (when posted) because 50% of this change is on the CA side, so there is no perfect reproductive test.


Nah.. Most clients will just start using the ISRG Root X1 from January 11 on. That isn't wrong.

Personally, I don't think there is anything wrong with not supporting ancient OSses.. Probably filled with a huge amount of bugs, security issues, exploitable stuff et cetera.


Fingers crossed - legs crossed - eyes crossed - lol

1 Like

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.

1 Like

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


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.

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?

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 :stuck_out_tongue: ).

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..

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. :confused:.

1 Like

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.. :slightly_frowning_face:

1 Like

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 :wink:

1 Like

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


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

The reasoning is captured in the first foot note:


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.