Must have more CAA records or fewer accounts

Help
1

A while ago, we added the CAA protection mechanism to our DNS, and more recently, we enhanced the LetsEncrypt-related CAA record with account restriction.
Now is already the second time that I ran into renewal issues because of this - as in: LE (correctly) refused a renewal because I forgot that not all boxes use the same account.

It seems that I have the following options

  • Remove the account specification from CAA completely (not desired)
  • Create CAA records for every account used on any applicable hosts (tends to clobber DNS)
  • Sync the hosts such that there is one account to rule them all (sounds best to me)

My current solution is the second option, but I'd like to switch to the third.

Q1: Is there any reason to think that the third option is actually a horrible idea?

I know that the accounts are represented by three files "meta.json", "private_key.json", and "regr.json" in folder "/etc/letsencrypt/accounts/(acme hostname)/directory/(random hex code)" and are referenced in the files "/etc/letsencrypt/renewal/(certificate name).conf" as "account = (random hex code)".
This seems to give us two ways to copy an account from server A to server B:

  • copy "/etc/letsencrypt/accounts/(acme hostname)/directory/(random hex code on A)" from server A to server B and edit all applicable renewal configurations to show "account = (random hex code A)" instead of "account = (random hex code B)"
  • or copy the three files in "/etc/letsencrypt/accounts/(acme hostname)/directory/(random hex code on A)" on server A into "/etc/letsencrypt/accounts/(acme hostname)/directory/(random hex code on B)" on server B, overwriting the existing files

I wonder:

Q2: Is either (or both) of these methods is valid?

For example, I see that "meta.json" contains a "creation_host" field, so ...

Q3: Does it cause problems if the creation_host value does not reflect the current host?

Q4: And will later invocations of certbot automatically pick the copied account (which one does it pick if there are several accounts)?

Q5: Is there any problem with the method described in case the certbot versions on server A and server B differ?

Thanks in advance for your awesome replies

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: redeker.de

I ran this command: (automated certificate renewal)

It produced this output: CAA record for redeker.de prevents issuance
(in /etc/letsencrypt/letsencrypt.log)

My web server is (include version): Apache/2.4.52

The operating system my web server runs on is (include version): Ubuntu 22.04.2 LTS

My hosting provider, if applicable, is: N/A

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 2.3.0

2

This is what I find for CAA record using the online tool https://unboundtest.com/
https://unboundtest.com/m/CAA/redeker.de/FB4IYWZL

Query results for CAA redeker.de

Response:
;; opcode: QUERY, status: NOERROR, id: 55263
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;redeker.de. IN CAA

;; ANSWER SECTION:
redeker.de. 0 IN CAA 0 iodef "mailto:hostmaster@redeker.de"
redeker.de. 0 IN CAA 0 issue "globalsign.com"
redeker.de. 0 IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v01.api.letsencrypt.org/acme/reg/64051960"
redeker.de. 0 IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v01.api.letsencrypt.org/acme/reg/51517926"
redeker.de. 0 IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v01.api.letsencrypt.org/acme/reg/7807738"

----- Unbound logs -----
Mar 04 17:37:58 unbound[543883:0] notice: init module 0: validator
Mar 04 17:37:58 unbound[543883:0] notice: init module 1: iterator

1 Like
3

Thank you for confirming. I edited/formatted my post to better highlight the questions I'm actually asking.

2 Likes
4

Oh, @hagman I just noticed, picking just one for example,

You are referring to ACME v1 in the accounturi; ACME v1 is End of Life (EOL)

Please move forward to ACME v2

1 Like
5

This post was flagged by the community and is temporarily hidden.

2 Likes
6

I suggest copying the entire /etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org directory, and leave it at that.

As long as you only have one account present for that ACME server, it won't matter whether the renewal .conf files reference the wrong account. Certbot will use whatever account is present for that ACME server, and update the account parameter on its own.

6 Likes
7

I agree that it's probably the best option. And if your usage of Let's Encrypt gets even more complex, and you start hitting rate limits designed for smaller players or want to be on an allowlist for a new feature, that's all generally easiest if everything you're using is under one account.

The main downside I see would be around security of the account key. If it's installed on multiple systems, a compromise on any one of them means that any of your certificates across all your systems could be revoked, or a cached authorization reused to create a new certificate. I don't think that there's a huge risk there, but it's worth understanding that's the tradeoff. The ACME RFC actually claims that "Compromise of the private key of an account key pair has more serious consequences than compromise of a private key corresponding to a certificate," though I (and some others) aren't really completely convinced of that.

I know much less about certbot than @_az does, so following her advice is probably the way to go. If it were me, if I didn't have any existing meaningful ACME accounts (due to an approved rate limit increase or allowlist entry or whatnot), and depending on what scale you're talking about, I might just deauthorize all my existing ACME accounts, create a new one on a scratch VM, copy the whole certbot directory over everywhere, and set up certbot anew on each server, just because that way I wouldn't have to worry about these nuances you're talking about of which internal config files can be mixed-and-matched.

The other thing to consider, again depending on your scale, is if certbot is really the best client for you to be using. It's really designed and optimized around the case of running a server or two, or at least having each server administrated and considered separately, and while certainly people do use it for large-scale installations it might be worth considering what other options are out there that might serve your needs better. If you really like having centralized administration, and things like monitoring which certificates are up for renewal, and handling having your account key securely across multiple systems, there might be better choices. But if you're comfortable with certbot and what it does for you, I wouldn't move away from it just because of this.

I think that's probably just reporting what the ACME server has in the account object on what system created the account. There's no problem using the account key on a different system than the one which created it.

I think they'd probably work fine, but you're getting into situations that probably very few other people have tested.

Well, there's some weirdness around that. You can use the ACME v1 account URIs even when using the ACME v2 endpoints, and I believe some versions and upgrade paths of certbot do exactly that. I don't know how the CAA accounturi works with that, but it wouldn't surprise me if the v1 and v2 versions of the same account (like https://acme-v01.api.letsencrypt.org/acme/reg/64051960 and https://acme-v02.api.letsencrypt.org/acme/acct/64051960) were treated interchangeably by Boulder.

I appreciate your confidence in the people here, but there is no warranty, express or implied, that any reply here will in fact be "awesome". :wink:

6 Likes
8

I went for this side quest, and ... learned a lot, but unrelated.

Technically, I was already using ACME v2 as in: communicate with the acme-v02 endpoints to request certificates etc. And that's also what certbot show_accounts displays.
The accounturi, however, is indeed aptly named to contain a URI and not a URL. That is: It is used to identify, not to locate the account as a resource. As such, https://acme-v01.api.letsencrypt.org/acme/reg/64051960 identifies the account that was once issued on acme-v01 with number 64051960. This is still a correct identification of the account even when the original host is long dead; moreover, it is theoretically possible (and would be valid) that acme-v02 has issued, or will issue an account with number 64051960 as well, but that would be a different account.

And indeed, if I change my account manually from v01 to v02 (in the uri field of its regr.json, and in my case also in the CAA DNS record), attempts to use it result in an error "KeyID header contained an invalid account URL". I suppose that even if the same account number existed in v02, then this would fail due to an invalid signature.

So there's that. As far as I can tell, there is no necessity to update old accounts to new ones created on v02 instead of just using the v02 endpoints with an up-to-date client and valid traditional accounts. Should this ever be required though, it would ultimately amount to deleting the old account and creating a new one ...

5 Likes
9

Thanks, that is good to know. :slight_smile:

2 Likes