DST vs ISRG Chain as default?

Hi all,

Further to ISRG vs DST Root on R3

I've just run my latest certificate renewal and CTW appears to still be generating an intermediate R3 signed by the DST root. I just wanted to confirm this is the expected behaviour still, if no alternate chain is specified (As is my normal process, I took the PFX saved to C:\ProgramData\certify\assets<domain> and used OpenSSL to split this to a PEM & private key file for various applications)?

subject=C = US, O = Let's Encrypt, CN = R3
issuer=O = Digital Signature Trust Co., CN = DST Root CA X3

Is the correct string to specify an alternate chain of the ISRG X1 chain only (i.e. no DST Root issuer or included) "ISRG Root X1" ? I have an application still unfortunately running an old version of OpenSSL and I am beholden to the developer updating their embedded OpenSSL implementation, but I've read v1.0.x may not work with Android clients using the chain where DST and ISRG are included, so I want to avoid that.

2 Likes

Yes, ISRG Root X1 is likely the correct string to use with the chain selection. However, this can be ACME client specific. Paging @webprofusion to clarify since it appears you're running Certify the Web as your client.

4 Likes

Just to add, the certificate request was sent using CTW v5.2.1 Windows 10 build 20H2 - I've since updated to latest 5.3.5 .. My preferred chain field is blank.

2 Likes

I think the announcement you're looking for is this one:

As of May 4, the default chain will go from Leaf ← R3 ← DST Root CA X3 to Leaf ← R3 ← ISRG Root X1 ← DST Root CA X3, but it's the same root in both cases. (The alternate chain is not changing, and will remain Leaf ← R3 ← ISRG Root X1.) What you need to worry about is actually in September, when DST Root CA X3 expires and old version of OpenSSL won't trust any chain including it (even if the chain includes ISRG Root X1 which it would have trusted in and of itself).

So, if your systems already trust ISRG Root X1, you want the "alternate" chain that doesn't include the expiring DST Root CA X3 in it. But in fact "ISRG Root X1" will be in both chains starting May 4, rather than only being in the alternate. So it really depends on how your client selects the chain how things will work then. The right string is almost definitely "ISRG Root X1" to select that root, it's just I don't know if your client will be confused if it sees that certificate in the default chain and think that's what should be selected instead.

3 Likes

OK, so I think @petercooperjr confirms (thanks) that DST Root should still be the root until 4th May...

Would be great if @webprofusion can confirm the preferred chain string I should use to request the ISRG (only) chain to avoid the OpenSSL 1.0.x issue...

Thanks :slight_smile:

1 Like

I got tired of dancing around...

https://community.letsencrypt.org/t/request-for-official-ongoingly-updated-issuance-chain-topic/150334/2

2 Likes

@griffin I rarely visit these forums as for me it mostly "just works", but could not agree more! :slight_smile:

2 Likes

Yes, Certify The Web will use the root issuer name defined by Let's Encrypt, so ISRG Root X1, and from v5.3.1 will favor the first matching issuer in the chain (so if the same issuer is present in two chains the one that will be used is the one with the preferred issuer as the first cert in the chain).

You can set the preferred chain either at the ACME account level under Settings > Certificate Authorities, then, Add Account > Advanced, or you can set it per managed certificate under Certificate > Certificate Authority > Preferred Chain.

So, you can set the preferred chain on that managed cert now and re-request your certificate.

Note:

  • Windows sometimes caches the issuer information.
  • There are other Certificate Authorities, so sometime the cleanest solution in a specific scenario may be to use an one of the alternatives with a widely trusted root.
  • If you are using custom scripting for deployment, also check our the built-in Certificate Export (and Deploy to Generic Server etc) deployment tasks, as these may save you have to maintain custom scripting and can do things like deployment over ssh/sftp with encrypted stored credentials which also saves having credentials in scripts.
4 Likes

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