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