Is the preferred-chain 'DST X3 Chain' option live?

Help
#1

Now that the R3 intermediate is in place is the preferred-chain option live to allow clients to request the old DST chain?

I tried requesting a cert with the 'DST Root CA X3' chain using the certbot 1.10.1 client and it seems like the cert is still being issued by the new R3 intermediate.

I double-checked the debug log and the correct '--preferred-chain' argument is being parsed but when I look at the cert issued it still shows:

$ openssl x509 -in cert2.pem -text -noout | grep -i iss
Issuer: C=US, O=Let's Encrypt, CN=R3
CA Issuers - URI:http://r3.i.lencr.org/

$ more /var/log/letsencrypt/letsencrypt.log
2020-12-21 14:13:53,705:DEBUG:certbot._internal.main:Arguments: ['--manual', '--preferred-challenges', 'dns', '--force-renewal', '--preferred-chain', 'DST Root CA X3', '--manual-auth-hook'

$ ./certbot --version
certbot 1.10.1

1 Like
#2

Your certificate will always be issued by R3. Certbot does not have any choice in that respect.

Where --preferred-chain makes a difference is choosing between a version of R3 which is highly compatible (R3's issuer is "DST Root CA X3") or the modern one with slightly less compatibility (R3's issuer is "ISRG Root X1").

The ability to make that choice has been live for quite a while now.

Today, there has been yet another update in the situation: https://letsencrypt.org/2020/12/21/extending-android-compatibility.html . The entire --preferred-chain thing is now largely moot from the perspective of maximizing compatibility.

2 Likes
#3

Thanks @_az,

In this case the issue is that some services (Subscription Manager / Foreman RedHat Satellite specifically) verify the entire chain against one installed/stored from an RPM and changing the intermediate will break the verification.

Happy Holidays

Adding keywords for future searches:

Katello
Subscription Manager
The Foreman
rhsm
Custom Certs

1 Like
#4

So they verify not only the root but also the intermediates as a whole? Change out the intermediate and the chain breaks?

Well, that's an incorrect design choice. Intermediate certificates can change at any notice. For example, if suddenly there would be an incident with the R3 intermediate, Let's Encrypt can fallback to their backup intermediate R4. This could literally happen at any time, without any warning. Pinning intermediate should never be done.

Also, because I can't actually believe that Redhat would do such a thing: do you have proof of your statement?

2 Likes
#5

I'm guessing it was a simple programming mistake or an overly simplistic implementation.

Note that they don't verify against a cert store but rather against a specific set of cert files installed using RPM.

Perhaps they just start at the bottom of the PEM file and verify up assuming that each section will verify the previous one.

1 Like
#6

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