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 UACME(1)
-l, --alternate N
According to RFC 8555 - Automatic Certificate Management Environment (ACME) 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.
The alternate chain is in flux right now. Soon there will be multiple alternate chains when the ECC certificates come online. There was the intention to make
Admittedly, having inconsistent chain order/content places extra burden on ACME clients to interpret the chains being provided rather than making assumptions by keeping up with documentation/announcements.
Regardless, for what it's worth, I'm fairly certain your concerns will be taken into consideration by the @lestaff (if they haven't been already).
Is changing chains rare? That depends on the time scale you're talking about. Sure, it is likely that most ACME services will change the alternate chains they offer much less often (on the order of years) than their clients renew their certificates (on the order of months). But that's still much more often than most folks should have to care about their ACME client configuration (on the order of once ever). So by creating an inflexible alternate chain selection mechanism, you're effectively forcing your client's users to care about their ACME configuration more often, rather than less often.
No, we cannot implement stable alternate chain order. There are two constraints which prevent us from doing so:
We cannot offer the same alternate chains at all times at all, regardless of their ordering. For example, the current default chain (through R3 up to DST Root CA X3) must stop being served in the near future, as that DST Root CA X3 certificate is expiring. Therefore the set of chains we serve must change.
There are many clients which do not implement alternate chain selection at all (as it is an optional part of the RFC 8555 spec). For those clients, we must offer the chain that we believe to be the best default as the first chain. If our assessment of what the best default is changes, then we must change the order of the alternate chains in order to offer that chain first.
The key reason why this "doesn't work" (obviously it does work, technically and mechanically, but I would argue that it doesn't work in your users' best interest) is that it doesn't take into account why a user might want to use an alternate chain. It places all of the onus (researching what alternate chains exist, figuring out what order they're offered in, selecting the Nth such offered, determining if your Nth flag is zero-indexed or not, etc) on the user, and as a result both fails to adapt in the face of changing user requirements (they have to do all that work all over again) and in the face of a changing environment (their setting might start getting them the wrong thing when our chains change).
Instead, focus on "why would the user want an alternate chain?". When we think about this question, there are two main things which come up over and over again: either they want a chain that is more efficient than the default, or they want a chain which is more widely compatible than the default. What determines compatibility? The name of the root. So let users specify the name of the root they want to chain up to, and then have the client abstract away all of the effort of determining which chain that is.
I feels like this should be something abstract away, like --shortest-chain (select most short chain.pem) and most-competiable ( among paths it trust select a chain that notbefore date of root is most old)
If I understand right, then --preferred-chain X could be changed to rank chains by characteristics of X. Rank a chain where X is (presumed to be) a root higher. Rank a chain where X is an intermediate lower.
Under the new chains:
"DST Root CA X3" would choose the "New Default Chain" because it's the only chain with that issuer.
"ISRG Root X1" would choose the "New Alternative Chain" because "ISRG Root X1" ranks worse than "ISRG Root X1 (self-signed)", due to being an intermediate.
Under the current chains, the selection is straightforward and would remain unchanged.
This would allow us to avoid changing the semantics of the flag (still matches any issuer) and also to continue meeting user intent (I choose "ISRG Root X1" for efficiency, give me the efficient one).
Is this a reasonable interpretation of your advice?
IMHO it's a great option and was my initial attempt for my client.
The only drawback of using a fingerprint is that it's not "pretty" for humans, and people often won't know what they're choosing. That's why I decided to try and go with the Issuer/Subject combos.
If you go this route, make sure you don't hardcode the existing roots/options though; otherwise you'll have to expand the list as time goes on and new Roots/CAs are available.
I've implemented fingerprint based alternative chain selection on the master branch
This option allows selecting one such chain in one of two ways. A positive integer N makes uacme select the Nth alternative chain in the order presented by the server. A colon (':') separated list of two or more 2-digit hexadecimal numbers FP makes uacme select the first alternative chain containing a certificate whose SHA256 fingerprint begins with FP. In both cases uacme falls back to the main certificate URL if it cannot match an alternative chain or the download thereof fails.
(emphasis added). It sounds like you're taking the approach of
fetch a chain
for every cert in that chain:
a) if it matches the command line flag, early-return
go to (1)
I'd advise against this approach. For example, in the near future, our two chains on offer will be:
EE <-- R3 <-- ISRG Root X1 <-- DST Root CA X3
EE <-- R3 <-- ISRG Root X1 (self-signed)
An approach which considers the names of every cert in the chain cannot select the latter of these two chains, as it contains no unique names.
Now, you have worked around this by using full-certificate fingerprints (which will differ for the cross-signed and self-signed versions of ISRG Root X1) rather than just the certificate's Subject info. We do not publish fingerprints of our certificates. So that still puts the onus on the user to a) learn exactly how your client produces its fingerprint, and b) learn how to replicate that themselves. A less-technical person searching for how to do this will find confusing results about thumbprints, about sha1 fingerprints, about PEM vs DER, and about public key fingerprints, at the very least.
If that's totally fine with you, then by all means go for it. Maybe your client's audience is all folks who know how to fetch the root they want to chain to and compute a sha256sum over the raw DER bytes of the whole cert. If you're interested in targeting a wider audience, I'd suggest either going with a name-of-the-root approach, or adding additional documentation on how to produce the flag values.
The real question in my opinion is whether such a person should be managing a server.
uacme's audience is unix users who can read a manpage and dislike bloat (that includes myself). As far as the certificate fingerprint itself is concerned, firefox (and I'm sure other browsers) can show it with just a couple of clicks, see screenshot below:
By the same token, how are your engine rebuilding and tuning skills? If I don't know how to change out a transmission or diagnose cylinder misfirings, should I take the bus? Are you up on your discreet Fourier transforms, RLC loops, and latch designs? If not, I recommend avoiding RAM, batteries, cellular devices, processors, and TV remotes.
You should then go to a garage and get your car fixed. But certainly you shouldn't be running a garage.
Your choice of subjects is rather unfortunate: I am an embedded systems designer by trade and yes, I'm up on all of those.
Now please can we stop bickering and go back to the chain selection mechanism? Has anyone got any constructive feedback before I release the current beta?
Surely you get my point, but I can see things from your perspective. Since our respective clients (both ACME and human) seem to have opposite expectations in terms of complexity of usage, I suppose fuller coverage is a good thing.
As to the matter at hand, I tend to generally adhere to the KISS principle by asking what I as a user of my own software would want to experience.
