CAA Account Binding: What accounturi and validationmethods Do

What the two parameters actually do

Both attach to the issue and issuewild properties of a CAA record. accounturi carries a URI identifying one account at the named CA, and where it is present the CA may only treat that property as authorising issuance if it recognises the URI as the account making the request. validationmethods carries a comma-separated list of validation method labels, and permits issuance only where the method being used appears in that list.

The gap they close is worth stating plainly. A CAA record that says issue "letsencrypt.org" authorises Let's Encrypt. It does not authorise you at Let's Encrypt. Anyone in the world who can satisfy a domain-control check for your hostname against that CA gets a certificate, and your CAA record raises no objection, because the only question it was ever able to ask is which company signs.

That is a real gap in a few concrete situations. A hosting provider or CDN holding a wildcard DNS delegation. A stale deployment pipeline nobody decommissioned, still holding a working account key. A staging ACME account that somebody once pointed at production names. None of these is an exotic attack; they are the ordinary mess of an organisation that has been running for a few years, and account binding is the DNS-level answer to all three.

validationmethods answers a different question. Domain control validation methods are not equally hard to subvert from the network. An adversary who can influence routing to your web server can potentially satisfy http-01 without ever touching your DNS. Restricting the record to dns-01 means a CA will refuse an http-01 authorisation for that name even if it succeeds, which moves the whole validation path into the zone you control and, if the zone is signed, into material an attacker cannot forge.

When do CAs have to honour them?

Section 4.2.2.1.2 of the TLS Baseline Requirements says CAs SHOULD process accounturi and validationmethods as specified in RFC 8657, and that effective 15 March 2027 they MUST. That section was created by Ballot SC098, "Process RFC 8657 CAA Parameters", adopted on 13 May 2026 and effective from 16 June 2026 as Baseline Requirements version 2.2.8.

The distinction matters more than it looks. RFC 8657 has been published since November 2019 and Let's Encrypt has honoured accounturi for years, but until SC098 there was no industry-wide obligation on anyone. The RFC is blunt about the consequence: domains configuring CAA records for a CA must not assume the restrictions implied by these parameters are effective without an explicit statement from that CA. Publish accounturi for a CA that has not implemented it and you get a record that reads like a security control and enforces nothing.

Three further requirements land on the same 2027 date, and they are the parts that make the parameters usable beyond the ACME world:

One small compatibility note buried in the same section: the canonical form of a validation method label is lowercase, but a CA may match case-insensitively provided it documents that in its CP or CPS. Write your labels lowercase and the question never arises.

How to write the records

The parameters go inside the quoted issue value, after the issuer domain name, separated by semicolons. The issuer domain name always comes first. Both parameters are optional and may appear in either order. A record pinning issuance to one Let's Encrypt account and to DNS validation looks like this:

example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567; validationmethods=dns-01"

Two accounts need two records. RFC 8657 combines separate properties as a union, so a request satisfying either one is permitted:

example.com. IN CAA 0 issue "example.net; accounturi=https://example.net/account/1234"
example.com. IN CAA 0 issue "example.net; accounturi=https://example.net/account/2345"

The same union rule lets you split responsibilities by method. The following pair says account 1234 may only use dns-01 and account 2345 may only use http-01, which is a reasonable way to describe a DNS-driven renewal job and a web-server-driven one that both legitimately exist:

example.com. IN CAA 0 issue "example.net; accounturi=https://example.net/account/1234; validationmethods=dns-01"
example.com. IN CAA 0 issue "example.net; accounturi=https://example.net/account/2345; validationmethods=http-01"

What you must not do is collapse that into one record with two accounturi parameters. It is the most common mistake, it looks entirely reasonable, and it produces a record that authorises nobody at all.

Remember that issue does not cover wildcards on its own. If you rely on a wildcard certificate, the same parameters have to be repeated on an issuewild property, or the wildcard request will be evaluated against a record that does not exist.

How do you find your account URI?

For an ACME CA it is the ACME account URL, which for Let's Encrypt takes the form https://acme-v02.api.letsencrypt.org/acme/acct/1234567, where the trailing number is the account ID. Certbot 1.23.0 and newer prints it directly; older versions keep it in the uri field of the account registration file on disk.

certbot show_account

# Certbot older than 1.23.0:
cat /etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/*/regr.json

Three things reliably catch people out here. The staging environment issues completely separate account IDs, so an ID copied from a staging run pins your production record to an account that will never make a production request. A host that has been rebuilt without preserving /etc/letsencrypt/accounts comes back with a new account, and the old URI in DNS stops matching. And a managed platform that obtains certificates on your behalf usually holds its own account, so the URI you need is the platform's, not one you can read off your own server.

That last case is the one to check before you publish anything. If a CDN, load balancer or hosting control panel renews certificates for the same names, its account has to be in the record too, otherwise you will pin issuance to a machine that is no longer the one doing the issuing.

What if your CA does not speak ACME?

Then there is no ACME account URL to point at, and the CA defines its own URI format. From 15 March 2027 the Baseline Requirements require such a CA to publish that format in section 4.2 of its CP or CPS. For validation methods, the ca-tbr-<N> labels fill the gap: the number is the Baseline Requirements subsection, so ca-tbr-7 is the DNS Change method of section 3.2.2.4.7 and ca-tbr-19 is the ACME website-change method of section 3.2.2.4.19.

Certum is a useful worked example, because it is a commercial CA that already supports both parameters outside ACME. It recognises certum.pl and certum.eu as its issuer domain names, takes the accounturi value from the customer account in its certificate management panel, and accepts ca-tbr-7 for DNS-based verification:

example.com. IN CAA 0 issue "certum.pl; accounturi=<your account URI>; validationmethods=ca-tbr-7"

This is the part that turns account binding from a Let's Encrypt feature into a general control. An organisation-validated or extended-validation certificate is ordered through a portal, not an ACME client, and until ca-tbr- labels existed there was no way to express "only DNS validation" for that kind of order. If you are choosing where to buy, the DV, OV and EV certificates we issue come from Certum, so the syntax above is the one that applies. For any other CA, ask for its documented position before you publish the record, because RFC 8657 puts the burden of confirming support on you rather than on the CA.

Four ways to lock yourself out

RFC 8657 defines three conditions that make a property unsatisfiable, meaning it authorises no issuance whatsoever, and ordinary misconfiguration supplies a fourth. All four fail closed, none of them affects a certificate you already hold, and every one of them surfaces for the first time at renewal.

1. An accounturi the CA does not recognise. A typo, a deleted account, a URI from a different environment. The property is unsatisfiable, and if it is your only record for that CA, issuance stops.
2. More than one accounturi parameter on one property. Explicitly unsatisfiable under section 3 of the RFC. Use one record per account instead.
3. An account at the wrong CA. The RFC gives this as its own worked example: a property naming a domain belonging to CA A with an accounturi identifying an account at CA B is unsatisfiable. The parameter never overrides the issuer domain name.
4. A validationmethods list that excludes the method your client actually uses. This is the quiet one. Pinning dns-01 is a good idea right up until a colleague switches a renewal job to a webroot plugin, at which point the CA refuses an authorisation that would otherwise have succeeded.

There is a timing trap layered on top. Section 4.2.2.1 of the Baseline Requirements permits a CA that has processed a CAA record to issue within the record's TTL, or eight hours, whichever is greater. A correction you publish is therefore not necessarily in force the moment it propagates, and neither is a restriction. Lower the TTL on your CAA records before you start changing them.

What this does not protect

Nothing in RFC 8657 constrains a CA you did not name, or one that ignores CAA altogether. The parameters let a domain further restrict a CA it already has a relationship with; the capacity of every other CA to issue for your names is, in the RFC's own words, completely unchanged. Before treating this as a perimeter, know where it stops.

Delegation beats it. CAA lookups walk up the DNS hierarchy until they find a record. If control over shop.example.com is delegated to another party, that party publishes its own CAA records at that level and yours are never consulted. Account binding at the apex says nothing about a zone you handed to someone else.

It leans on DNSSEC. A CA supporting these parameters is required to perform CAA validation through a trusted DNSSEC-validating resolver, and since 2025 the Baseline Requirements have required DNSSEC validation on CAA lookups generally, with validation errors such as SERVFAIL explicitly not counting as permission to issue. That protection only exists if your zone is signed. Against an adversary who can intercept all validation traffic for an unsigned domain, the restriction can be forged along with everything else.

It is public. CAA records are readable by anyone, so publishing account URIs tells the world which accounts you use. Where the same account issues for several domains, that is a correlation anybody can compute. The RFC raises this itself and tells CAs to assume account URIs will become public knowledge.

None of that argues against using the parameters. It argues for keeping Certificate Transparency monitoring switched on afterwards, because CT is what covers the cases CAA structurally cannot.

Rolling it out without locking yourself out

The failure mode is silent, which is what makes the order of operations matter. A wrong parameter does not break TLS and does not break your site; it breaks the next issuance, and on a 90-day certificate that can sit undiscovered for weeks. Prove each step works before you rely on it.

1. Confirm your CA documents support. Until 15 March 2027 this is optional for them. An undocumented CA is not a reason to skip the record, but it is a reason not to count it as a control.
2. Lower the CAA TTL first, so the eight-hour floor in section 4.2.2.1 is the only lag you are fighting.
3. Inventory every account that legitimately issues. Servers, CI pipelines, the CDN, the load balancer, the control panel. Each gets its own record.
4. Add accounturi alone. Leave validationmethods out of the first change so a failure has one possible cause.
5. Force a renewal immediately rather than waiting for the scheduled one. On Certbot, certbot renew --force-renewal --cert-name example.com turns a problem you would have found in seven weeks into one you find in seven seconds.
6. Repeat for issuewild if you use wildcard certificates.
7. Only then add validationmethods, matching what your client actually does today rather than what you would prefer it did.

You can read back what is actually published with dig CAA example.com +short, which is worth doing from outside your own network — a split-horizon resolver that answers differently for internal clients has fooled better engineers than either of us.

A closing opinion, since the parameters are not equally worth your time. For a single domain renewing through one ACME account, accounturi is a genuine improvement that costs one DNS record and closes a real gap. validationmethods is narrower in benefit and wider in blast radius, and it earns its place mainly when your zone is signed and you want the whole validation path inside DNSSEC. If your zone is not signed yet, sign it first. That single change does more for the integrity of your certificate issuance than either parameter can do on its own.