Boulder(pebble)/certbot specific - matching a key to an acme directory offline

[jvanasco]

I’m in the home-stretch of rewriting our certificate-manager/client and I’m trying to work out the last bits of importing Certbot LetsEncrypt accounts.

Under ACME-V1, all the resource locations were predictable. When importing an account, I could easily know the corresponding server.

Under ACME-v2, I know the following details:

1. The directory might be in a given location, for example:

   https://acme-v02.api.letsencrypt.org/directory

2. The account resource could be anywhere, it’s most likely in a given location, but still…:

   https://acme-staging-v02.api.letsencrypt.org/acme/acct/xxxxxxx

The RFC usually places directory under acme (/acme/directory), but states it could be anywhere and pebble departs from this model.

Is there any reasonable likelihood that LetsEncrypt will mount multiple ACME services/directories on the same domains?

The reason why I am asking - Certbot doesn’t save (or did not save when my accounts were created) the directory information with the accounts in /etc/letsencrypt. When importing these accounts, I’m trying to match them up with the correct provider.

Also, given this filepath:

/etc/letsencrypt/accounts/acme-staging-v02.api.letsencrypt.org/directory/xxxxx

Would I be safe to assume that Certbot is stating the ACME-v2 “directory” is acme-staging-v02.api.letsencrypt.org/directory

Going through the certbot code, it seems that an _account_dir_path is build off a server_path, and the “server_path” is acme-staging-v02.api.letsencrypt.org/directory.

This would suggest to me the accounts within that file directory are correlated to the server-path directory.

I’m sorry if this is too pedantic, but I’ve been caught between writing to a spec, and reverse engineering various bits of Certbot to ensure compatibility.

This certificate system is designed for large clusters, so i’m trying to ensure everything imports correctly

[Osiris]

@jvanasco

Certbot doesn’t save (or did not save when my accounts were created) the directory information with the accounts in /etc/letsencrypt .

It should have the directory URI saved in the renewal configuration files under the variable server.

[jvanasco]

Thanks. I just looked this up, and it’s a bit awkward. I think I will just rely on the filepath to discern the server – for now.

The renewal files do have the following two fields:

account = xxxxxxxxxxxxxxxxxxxxxxxx
server = https://acme-v02.api.letsencrypt.org/directory

and that does map to this filesystem path…

 /etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/xxxxxxxxxxxxxxxxxxxxxxxx

however if i look at this file:

 /etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/xxxxxxxxxxxxxxxxxxxxxxxx/regr.json

I only have an account URI in the json payload:

https://acme-v02.api.letsencrypt.org/acme/acct/{ddddddd}

If I rely on the renewal data for the directory info, I can only discern the account info for keys with an active renewal. There’s nothing in the actual account file - except the certbot path, that suggests what the “server” is.

[schoen]

Certbot doesn’t have a very systematic approach to this in some sense, but the idea is that the server is stored, if necessary, in the individual certificate renewal configuration files in /etc/letsencrypt/renewal, and then when renewing using a particular server, say, https://acme.api.example.com/directory, Certbot would first look in /etc/letsencrypt/accounts/acme.api.example.com/directory to find the account information. In turn the account URI is indeed saved inside that JSON blob that you see, and it gets used by Certbot in the ACME protocol.

The possibly non-systematic or confusing thing about this is that the directory URL for the ACME service is not stored anywhere in /etc/letsencrypt/accounts (except implicitly in the subdirectory paths). I think the general reason for this is, first, kind of like videogame savefiles (we just need a serialization that will make the code that cares about these objects happy when we deserialize it, and it’s not particularly meant to be human-readable, human-editable, or avoid containing extraneous data), and second, because Certbot doesn’t know everything that ACME or a particular ACME version or implementation may choose to make available in connection with a registration. So we don’t have a fixed overall schema for account information, maybe based on an intuition that the account information or metadata might change over time or from service to service.

[jvanasco]

Thanks, Seth. …