Interest in ACME CAA record delegation

Issuance Tech
1

Hello Everyone,

Over the past few months, I’ve become increasingly interested in the ACME ecosystem.

One technology I find particularly fascinating is ACME CAA records, which I believe are significantly underutilized. Specifically, the account binding feature has great potential to enhance security. However, one of the main challenges is that setting up these records can be complex and often requires manual effort. To address this issue, I propose a delegation mechanism that could simplify the process.

In the current state, it’s already possible to automate the setup of CAA records. For example, the process could work as follows:

  1. A reverse proxy requesting certificates from a provider like Let's Encrypt first creates an account using the ACME API.
  2. It then adds the corresponding ACME CAA record with the newly created account included in the account binding tag.
  3. After verifying DNS propagation, the reverse proxy proceeds with certificate issuance as usual.

However, there is a challenge with this approach: the reverse proxy or ACME client requires direct access to modify the DNS records of the domain. This situation is similar to the one encountered when using DNS-01 validation for certificates. In that case, the ACME client only needs access to the _acme_challenge subdomain, allowing for improved security through tools like acme-dns or by using more restrictive DNS API permissions.

Applying a similar delegation mechanism for CAA records could strike a balance between security and usability. By limiting the required DNS access and incorporating such tools, the process would become both safer and more practical.

In this post, I wanted to hear your second opinions on this topic or learn from users who have implemented automatic CAA record creation.

2

How CAA will resolved is defined in RFC8659 and enforced in CA/B baseline requirement section 3.2.2.8: individual CA may implement additional feature from tags it but it must follow rules define in those documents.

As part of the Certificate issuance process, the CA MUST retrieve and process CAA
records in accordance with RFC 8659 for each dNSName in the subjectAltName
extension that does not contain an Onion Domain Name. These practices MUST be
described in Section 4.2 of the CA’s Certificate Policy and/or Certification Practice
Statement, including specifying the set of Issuer Domain Names that the CA recognizes
in CAA “issue” or “issuewild” records as permitting it to issue.

2 Likes
3

Thank you for the input! That makes the possibility of such an implementation a tad more difficult than I initially thought. From my perspective, simplifying account binding is the most critical issue however. Accounts are far more dynamic and prone to change than the issuers themselves.

Given that, I believe an implementation like the following could still align with the CA/Browser Forum Baseline Requirements:

example.com. IN CAA 0 issue "letsencrypt.org; \
  delegation=caa.example.com"
caa.example.com. IN CAA 0 issue "letsencrypt.org; \
  accounturi=https://example.net/account/1234"

Now I am just thinking "aloud", and there would be alot of open questions with my example.

  1. Should the delegated entries also follow the CAA format?
  2. Do the issue or issuewild tags need to match at all levels?
4

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.