Switch intermediate certificate from IdenTrust to ISRG signed


#1

Good day,

I’m using certbot in Python and the code is:

certbot.main.main([
   'certonly',                             # Obtain a cert but don't install it
   '-n',                                   # Run in non-interactive mode
   '--agree-tos',                          # Agree to the terms of service,
   '--email', email,                       # Email
   '--dns-route53',                        # Use dns challenge with route53
   '-d', domain,                           # Domain to provision cert for
   # '--staging',                            # TODO Uncomment for testing
   # Override directory paths so script doesn't have to be run as root
   '--config-dir', WORK_DIR,
   '--work-dir', WORK_DIR,
   '--logs-dir', WORK_DIR

])

The issue is that certbot always chooses as intermediate Let’s Encrypt Authority X3 (IdenTrust cross-signed) despite the fact there is 2 of them.

Is there any way to tell certbot to take another intermediate (Let’s Encrypt Authority X3 (Signed by ISRG Root X1))?

Thanks,
Sergey


#2

AFAIK, in ACME the issuer/intermediates come from the CA. I think the switchover to the ISRG root would happen as a result of a CA-based flag.

If you wanted to use the ISRG-signed intermediate, I think you might need to manually merge combine cert.pem with the one you wanted to use.

This may prove to be a fragile/non-conformant move as the CA may move to X4 at any moment.

Edit: I checked what Boulder does - it doesn’t appear to implement the sending of alternate chains from the spec. So Certbot can’t do anything about it.


#3

Oh, I see.

Thank you for the answer.


#4

Hi @_az

there are no two different intermediate certificates.

Checking community.letsencryt.org with FireFox -> ISRG root.
Checking community.letsencryt.org with Chrome -> DST Root

It’s only a client-decision which root certificate is used.


#5

Sorry, that’s simply wrong. There are distinct intermediate certificates with the same name, same private key, different signer.

Check “Intermediate Certificates” on https://letsencrypt.org/certificates/

Alternatively:


#6

As @_az said, yes, there is: it’s the principle of cross signature: the certificates are identical but signed by different roots.

Yes, the presented intermediate may only help in that decision. But if the browser know (or download) the other one, it may build another trusted path.


#7

Do you know how they planned to implement to choice between the current Root and the future ECDSA one? It may be the same mechanism that allow to switch to another Root path, no?


#8

I agree that this is a correct description of the browser behavior that @JuergenAuer saw.

@illapikov, currently ISRG doesn’t suggest presenting the ISRG-signed intermediate certificate to the general public by default because although the ISRG root is trusted by all of the mainstream browsers, there is a large installed base of older devices and operating systems that haven’t received the relevant browser updates. So presenting the ISRG-signed intermediate to a heterogeneous client base may reduce compatibility. Over time, the ISRG root should be trusted by a higher and higher fraction of deployed browsers and there may be a point in the future starts to recommend its use by default.

As other people have correctly said in this thread, there’s no way to use the other intermediate automatically with Certbot; you would have to edit your chain manually. This is because there’s currently no circumstance in which Boulder sends the other intermediate as part of the recommended chain. If you have a particular reason to want to encourage clients to build this trust path instead of the other one, you can edit your chain manually (or use a Certbot deploy-hook to invoke a script that you write to edit the chain).


#9

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