In the near future, Let's Encrypt intends to update the default and alternate chains that we provide. In short, we'll be offering two chains that users can choose between:
Subscriber Cert <-- R3 <-- ISRG Root X1 <-- DST Root CA X3 (self-signed)
Subscriber Cert <-- R3 <-- ISRG Root X1 (self-signed)
These chains come with three intertwined issues, the third of which is relevant here:
- The second chain (which terminates at ISRG Root X1) doesn't work on older Android devices, which don't trust ISRG Root X1. This issue is solved by offering the other chain as the default.
- The first/default chain (which terminates at DST Root CA X3) doesn't work with older versions of openssl, because that root will expire and old openssl will fail to realize it could have stopped at ISRG Root X1. (This is the same problem as the AddTrust expiration from May of last year.) This issue is solved by offering the shorter chain as an alternate.
- The alternate chain contains no unique names, so certbot users cannot select it using the current
--preferred-chain mechanism.
Today, certbot's --preferred-chain selection mechanism looks at every certificate in the chain, to see if any of them have a name which matches that supplied by the user. Unfortunately, there is no name which exists in the alternate chain above which does not exist in the default chain above, so there is no name which a user could provide to cause certbot to select the alternate chain.
I'd like to update certbot to have a different preferred chain mechanism which can distinguish between these chains. There are a few options I can think of, and probably more that I haven't:
- Only care about the name of the root certificate, not any other certificates in the chain
- Distinguish between chains by qualitative criteria, like "pick the shortest"
- Distinguish between certificates by their fingerprint, rather than their name
In addition, there are multiple ways (and again others I haven't yet thought of) that changes like the above could be implemented:
- Change the semantics of the existing
--preferred-chain flag (probably backwards-incompatible, but would anyone actually be broken)
- Add a new flag with the new semantics
- Add a new flag which changes the semantics of the existing
--preferred-chain flag
I'm happy to make this contribution / write a PR for this, but I wanted to make sure there was a place to have a design discussion first. I don't want to just toss a PR out there and then have it be aiming towards a solution that you don't like.
In the near future, Let's Encrypt intends to update the default and alternate chains that we provide. In short, we'll be offering two chains that users can choose between:
These chains come with three intertwined issues, the third of which is relevant here:
--preferred-chainmechanism.Today, certbot's
--preferred-chainselection mechanism looks at every certificate in the chain, to see if any of them have a name which matches that supplied by the user. Unfortunately, there is no name which exists in the alternate chain above which does not exist in the default chain above, so there is no name which a user could provide to cause certbot to select the alternate chain.I'd like to update certbot to have a different preferred chain mechanism which can distinguish between these chains. There are a few options I can think of, and probably more that I haven't:
In addition, there are multiple ways (and again others I haven't yet thought of) that changes like the above could be implemented:
--preferred-chainflag (probably backwards-incompatible, but would anyone actually be broken)--preferred-chainflagI'm happy to make this contribution / write a PR for this, but I wanted to make sure there was a place to have a design discussion first. I don't want to just toss a PR out there and then have it be aiming towards a solution that you don't like.