Watch: CAA Account Pinning Explained
CAA account pinning uses two RFC 8657 parameters on your CAA issue/issuewild records — accounturi and validationmethods — to restrict certificate issuance to a specific ACME account and a specific validation method. It closes a real gap: base CAA says which CA may issue for your domain, but not who at that CA. With account pinning, an attacker who briefly hijacks your DNS still can't get a certificate, because they don't hold your ACME account key. As of CA/Browser Forum ballot SC-098v2, every public CA must support these parameters on 2027-03-15 — with no phase-in. The one catch that bites people: a wrong accounturi silently blocks your own renewals, so you test before you enforce.
example.com. CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678; validationmethods=dns-01"
What RFC 8657 actually changes
Certificate Authority Authorization (CAA) is a DNS record telling CAs whether they may issue for your domain. The base spec is RFC 8659. A plain issue record —
example.com. CAA 0 issue "letsencrypt.org"
— says only Let's Encrypt may issue, but it doesn't stop anyone who controls the domain, including a DNS hijacker, from getting a cert through that CA.
RFC 8657 (published November 2019) added two parameters to the issue and issuewild properties: accounturi (narrows authorization from a CA to a specific account) and validationmethods (narrows how control may be proven). These were optional for years; SC-098v2 makes support mandatory in March 2027, and practitioners are deploying the records now.
The two parameters, precisely
accounturi — pin issuance to one account
Binds authorization to a single account identified by its URI. A CA must only treat the property as authorizing issuance if it recognizes the URI as the account making the request. In ACME terms that URI is your account URL, and control is proven by your account key — a DNS hijacker without that key is stopped.
Two rules from RFC 8657 you must know:
- A property with an invalid or unrecognized accounturi is unsatisfiable — a typo fails closed, against you.
- A property with multiple accounturi parameters is also unsatisfiable — use one per property record.
validationmethods — pin how control is proven
Takes a comma-separated list of validation-method labels (for ACME, method names like dns-01, http-01, tls-alpn-01). Setting validationmethods=dns-01 means the CA must refuse HTTP validation even for your own account. Paired with DNSSEC, dns-01 gives a cryptographically strong path and removes weaker HTTP-based ones as attack surface.
One CA-consistency rule
RFC 8657 requires a CA to apply these parameters consistently across all its issuance systems. That's the CA's obligation, and it's why the SC-098v2 mandate matters — it forces uniform behavior across the ecosystem.
Find your account URI (per CA)
The reliable, CA-agnostic way: the account URI is the account URL your ACME client recorded at registration (the Location header returned on account creation). Read it from your client rather than building it by hand.
Let's Encrypt
Account URIs look like https://acme-v02.api.letsencrypt.org/acme/acct/12345678
Retrieve via:
- ›certbot 1.23.0+:
certbot show_account - ›Older certbot: read the
urifield in/etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/*/regr.json - ›acme.sh: from its account config
- ›cert-manager: from the
status.acme.urifield on the Issuer/ClusterIssuer
Google Trust Services
ACME directory is https://dv.acme-v02.api.pki.goog/directory and its CAA identity is pki.goog. Account URIs live under that host; retrieve the exact URI from your client's stored account record. GTS requires External Account Binding (EAB).
example.com. CAA 0 issue "pki.goog; accounturi=https://dv.acme-v02.api.pki.goog/directory/<account-id>; validationmethods=dns-01"
DigiCert
Public ACME runs through CertCentral. The current directory is https://one.digicert.com/mpki/api/v1/acme/v2/directory (the legacy acme.digicert.com endpoint was retired February 24, 2026) and its CAA identity is digicert.com. DigiCert ACME requires EAB.
Take the account URI from the account record your client stored; because DigiCert's account-URI path isn't publicly documented like Let's Encrypt's, read it from your client rather than assuming a format.
Deploy it safely (the part that locks people out)
The failure mode is silent — a wrong accounturi throws no error when you publish; it fails weeks later at your next renewal as a CAA rejection in the CA's issuance log. Treat rollout like a production change.
- 1
Inventory every issuer first
List every account and validation method that legitimately issues for the domain — primary ACME clients, plus CI/CD pipelines, load balancers, CDNs and WAFs (Cloudflare, Fastly, cloud load balancers, managed platforms often hold their own accounts), and any third party or SaaS issuing under your domain. The number-one cause of a self-inflicted outage is a forgotten second issuer.
- 2
Get the syntax exactly right
Parameters live inside the quoted value separated by semicolons. The accounturi match is exact — a trailing slash, wrong acct ID, or http vs https makes it unsatisfiable. One accounturi per property — for two accounts use two separate issue records.
- 3
Test before you enforce
Start with a short TTL on the CAA record so you can back out fast. Stage in a low-risk zone or subdomain if you can. Force a renewal against the pinned account (e.g. certbot renew --force-renewal on a test cert, or your client's equivalent) and confirm issuance succeeds. Only after a real issuance succeeds should you trust the record, then raise the TTL back to normal.
- 4
Keep a rollback ready
If renewals start failing, remove or correct the accounturi and let the short TTL expire. Because CAA is checked at issuance time, backing out restores normal issuance on the next attempt — no reissue needed for existing valid certs.
What breaks if you get it wrong — and the deadline
Be precise — certificates do not break on 2027-03-15. What happens is that CA support for these parameters becomes mandatory under SC-098v2; existing certs keep working. The risk is entirely misconfiguration on your side: a wrong accounturi breaks at your next renewal, not on any calendar date.
So the deadline isn't a cliff — it's a reason to adopt the control while you have time to test it. Account pinning is one of the few CAA features that materially raises the cost of a DNS-hijack misissuance attack, and the mandate guarantees every public CA will honor it.
Checklist
- Base CAA issue record already in place and correct
- Inventoried every account/method issuing for the domain (including CDNs, LBs, CI/CD, third parties)
- Retrieved the account URI from your client's account record — not hand-built
- Record syntax verified: semicolon-separated params, exact accounturi, single accounturi per property
- Short TTL set on the CAA record
- Forced a real renewal through the pinned account and confirmed issuance succeeded
- Rollback understood; TTL restored after verification
Reference record:
example.com. CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678; validationmethods=dns-01"