My organisation gets certificates from Sectigo, and they provide us with an ACME endpoint that uses an HMAC/ID pair in order to identify the requester.
We just changed HMAC configs for an instance of certbot, and so I dropped in the new HMAC/ID pair onto the command line in order to try to get a new cert, like so:
Boy was I surprised when certbot wouldn't authenticate using these new credentials I've supplied - it looks like it was silently ignoring this new config and using the cached one, which, in this instance, wasn't allowing me to get certs verified at all until I removed the old creds at /etc/letsencrypt/accounts/acme.sectigo.com/v2/OV/
Is this a bug/feature, or did I miss something? It would have been nice for certbot to at least tell me that it's going to ignore the credentials I'm giving it on the command line in preference for the ones it currently has.
This also implies that certbot is not capable of handling more than one set of credentials for an organisation i.e. for carefully tying down domain certificate controls. Is this right? How would one go about making that work, should one want to?
If I locally test EAB key binding, I noticed certbot doesn't store the EAB ID and EAB HMAC at all locally. So my theory is (I haven't looked at the ACME RFC yet) is that the EAB stuff is only used when generating a new account and when your account is being generated at the remote ACME server, it uses the EAB details to link the ACME account to the EAB details, but only at that moment.
I'm not sure if the ACME protocol even allows updating the EAB bindings for an already existing account. If it does, this might be a nice feature request for certbot.
It seems the ACME RFC does not forbid updating an EAB. Section 7.3.2 of the RFC specifies updating an account in a very specific way. So in theory it should be possible. However, I'm not sure if the ACME server used by Let's Encrypt nor Sectigo supports that. Certbot itself doesn't support it at least.
Hm, it seems Boulder doesn't support EAB at all? At least, I can't find ANYTHING about it in the source code. However, it's also not mentioned in boulder/acme-divergences.md at main · letsencrypt/boulder · GitHub ? Which should be updated anyway I think, as I believe Let's Encrypt/Boulder mandates POST-as-GETs since a while back now. Perhaps @jsha could enlighten us about Boulder supporting EAB? Maybe Sectigo developed EAB support in Boulder themselves? As it seems https://acme.sectigo.com/v2/OV is running boulder, looking at the error message presented when surfing to https://acme.sectigo.com/v2/ in my browser.
I was always under the impression that EAB was specifically only used during ACME account creation.
It would surprise me if EAB supporting CAs had a method to update the binding for an existing account. My guess is that if you have new EAB credentials, you must create a new ACME account to go with them.
Hmm. Am I missing a mechanism to do that? Attempting to register a new account to the same external server using:
certbot register --server https://acme.sectigo.com/v2/OV --eab-kid (NEWID) --eab-hmac-key (NEWKEY)
only gives me:
There is an existing account; registration of a duplicate account with this command is currently unsupported.
letsencrypt.log doesn't give me any other useful information at logging level 20.
Edit: I keep forgetting that chevrons are bad in Forumland! Switching to redaction notices with ().
That's because certbot doesn't formally support multiple accounts for the same ACME server. However, you can "hack" your way around that a little bit by temporarily move an existing account directory under /etc/letsencrypt/accounts/acme-server/ to a temporary location, register a new account and move the old account back from the temporary location to the original location in /etc/letsencrypt.
However, if you have multiple accounts, you can't non-interactively use certbot any longer, as certbot will ask the user which account should be used, which can't be done non-interactive. If you're using certbot from CLI manually, that isn't an issue. Also, the account used is stored in the renewal configuration files, so automatical renewals will be fine too.
I think the thing that got me turned around is that that warning that 'registration of a duplicate account is currently unsupported' is only visible upon using the certbot register subcommand, and it doesn't come up at all using certbot certonly, so I spent a long time chasing my tail trying to figure out what is going on.
Is that alone a valid bug/feature request to file on github?
You might want to check and search if such a feature request wasn't issued at the certbot github repository already once in the past. If not, I think the github repository is the perfect place to request such a feature indeed.
Also, perhaps the EAB wasn't mentioned in a previous feature request, so if it was turned down in the past without acknowledging the struggles due to EAB is just bound to a single account, I'd say try to open a new feature request anyway.