Quoting from https://letsencrypt.org/2020/12/21/extending-android-compatibility.html
Today, some ACME clients are able to instead request an alternate chain, if their user has configured it. We currently provide the option of getting the chain: Subscriber Certificate < – R3 < – ISRG Root X1. We will continue to offer this same chain as an alternate. However, note that most ACME clients don’t yet have a way to select this alternate chain (for example, Certbot selects chains by looking to see if they contain a given Issuer Name, but this chain doesn’t contain any Issuer Names which the high compatibility chain above doesn’t). We’ll be working with ACME client developers to create more flexible chain selection mechanisms going forward.
My approach to the above is based on the - possibly unjustified - assumption that an ACME server would only seldom change alternate chains and the order it serves them. With that assumption, I coded a very simple uacme option allowing selection of the Nth alternate chain - see manpage at https://ndilieto.github.io/uacme/uacme.html
-l, --alternate N
According to https://tools.ietf.org/html/rfc8555#section-7.4.2 the server MAY provide one or more additional certificate download URLs, each pointing to an alternative certificate chain starting with the same end-entity certificate. Specifying this option makes uacme choose the Nth alternate link. If the server does not provide it or the download fails, uacme falls back to the main certificate URL.
Therefore I'd like to ask:
-
is my assumption justified?
-
if not, is it maybe something Let's Encrypt could decide to implement? I would think that a stable alternate chain order is desirable anyway, and it doesn't require making any changes to RFC8555.