CAA accounturi and validationmethods: Prepare for March 2027

From 15 March 2027, publicly trusted certificate authorities must process the RFC 8657 CAA parameters accounturi and validationmethods. Domain owners do not have to publish them. Use them only when you directly control the ACME account and know the validation challenge used for every certificate on the name.

That distinction matters. A basic CAA record answers which certificate authority may issue. These advanced parameters can also answer which customer account and which validation method that authority may use. A typo can block the next certificate order, so the change needs the same care as a firewall rule.

If you only need a normal CAA allow-list, start with our general CAA record guide. If your certificates come from cPanel AutoSSL, use the cPanel and AutoSSL-specific CAA guide instead. This article is for operators who manage an ACME client such as Certbot themselves.

What changes on 15 March 2027?

CA/Browser Forum Ballot SC098v2 says certificate authorities must process the CAA parameters defined in RFC 8657 from 15 March 2027. The obligation is on the CA. It does not force a website owner to add new DNS records, and it does not mean the feature is unavailable before that date.

The two parameters are:

• accounturi: authorizes issuance only through a specific ACME account at the named CA.
• validationmethods: authorizes only named ACME challenge methods, such as dns-01.

These parameters sit inside an issue or issuewild property. They do not replace normal domain control validation. A CA still has to validate the domain and meet its other issuance requirements.

Should you use these parameters?

• You run Certbot or another ACME client and own the account: consider both parameters and test on a non-critical hostname first.
• Shared hosting with cPanel AutoSSL: avoid accounturi; avoid validationmethods unless your host documents the exact renewal path.
• Cloudflare Universal SSL edge certificate: avoid both because Cloudflare manages the issuance account and CA set.
• Several teams or tools issue certificates: inventory every issuer, account and challenge before adding either restriction.
• No renewal test or quick DNS restore: keep a basic CAA allow-list only.

The strongest candidate is a server where one team operates one ACME account, knows the challenge method, and has console access plus a tested DNS rollback.

Step 1: Inventory every certificate path

Before changing DNS, list the certificate names, issuers and renewal tools. Check the CAA answer at the exact name and at its parent because CAA processing can climb the DNS tree.

dig example.com CAA +short
dig www.example.com CAA +short

Also check CNAME targets. CAA processing follows CNAMEs, so a restrictive record on a target can affect issuance for the alias.

Save the output and export the authoritative DNS zone. Record who renews each certificate: Certbot, a hosting panel, a CDN, a load balancer or another service. Stop if any path is unknown.

Step 2: Find the production ACME account URI

On a Certbot server, this command displays the current account details:

sudo certbot show_account

For Let's Encrypt production, an account URI resembles this:

https://acme-v02.api.letsencrypt.org/acme/acct/EXAMPLE_ACCOUNT_ID

EXAMPLE_ACCOUNT_ID is a placeholder. Copy the complete URI from your own output. Do not guess it, and do not use the URI from another server or from the staging environment.

If show_account returns no account, if several ACME clients run on the server, or if a hosting panel owns the renewal job, do not add accounturi yet.

Step 3: Identify the validation method

Look at the ACME client configuration and recent renewal logs. Common identifiers recognized by Let's Encrypt include:

• http-01: the CA retrieves a token over HTTP.
• dns-01: the CA checks a DNS TXT record; this is required for wildcard certificates.
• tls-alpn-01: the CA validates a special TLS response.

Do not infer the method only from the current certificate. The certificate does not record how it was validated. Confirm the method in client configuration or logs.

Step 4: Write one narrow record

An account-pinned Let's Encrypt record looks like this:

example.com. CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/EXAMPLE_ACCOUNT_ID"

A method-pinned record that allows only DNS validation looks like this:

example.com. CAA 0 issue "letsencrypt.org; validationmethods=dns-01"

You can combine both restrictions in one property:

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

Replace the domain and account URI with your real values. Preserve every other CA or service your inventory found. If wildcard and non-wildcard certificates follow different paths, review issuewild separately; publishing any issuewild property changes which properties control wildcard issuance.

Step 5: Deploy with a rollback window

Make the change when someone can watch renewal tests and restore DNS. Keep the previous record set in a text file and note the DNS TTL.

After the change reaches authoritative DNS, query it directly and then through a public resolver:

dig example.com CAA +short
dig @1.1.1.1 example.com CAA +short

The returned property must match the account URI and challenge method exactly. Check every certificate name and relevant CNAME target.

Step 6: Test without confusing staging and production

Certbot documents renew --dry-run as a test against the Let's Encrypt staging environment:

sudo certbot renew --dry-run

There is an important catch: staging and production use separate ACME accounts. A record pinned only to the production accounturi can correctly reject the staging account, causing a dry run to fail even though the production account is authorized.

For an account-pinned design, test first on a dedicated non-critical hostname or test domain with its own staging account and matching CAA record. Do not weaken a production record merely to make a staging test pass. If you need to test on the production name, use a documented maintenance window and a separately authorized staging property only after confirming the plan with your CA.

For validationmethods without accounturi, a dry run is still useful when the staging client uses the same challenge method. Read the full error rather than treating every failure as a CAA problem.

Rollback

If issuance reports a CAA authorization error:

1. Remove only the new parameterized property.
2. Restore the saved basic CAA record set.
3. Wait for the authoritative DNS answer to show the restored value.
4. Query every affected name again.
5. Repeat the renewal test that is valid for your environment.

Do not delete unrelated CAA records added for a CDN, hosting panel or second certificate authority. A rollback should return to the exact saved state.

Common failures

The account URI belongs to staging

Symptom: production issuance is rejected even though the account number looks familiar.

Fix: compare the complete URI, including the ACME hostname, with sudo certbot show_account in the production environment.

A wildcard renewal fails

Symptom: normal certificates renew but *.example.com does not.

Fix: verify the wildcard uses dns-01 and inspect issuewild. Once an issuewild property exists, the issue properties do not authorize wildcard issuance.

AutoSSL or a CDN stops issuing

Symptom: a certificate managed outside your server reports a CAA error.

Fix: restore the previous record set. The external service may use an account or CA you do not control, which makes account pinning unsuitable on that name.

The record looks right but the CA still rejects it

Check the authoritative answer, parent labels, CNAME targets, quoting and spaces. Compare the CA identifier and parameter support with the CA's current documentation. If the record is inherited from a parent, changing only the child-side control panel may not change the effective answer.

Practical security value and limits

accounturi can reduce the chance that another account at the same CA obtains a certificate for your name. validationmethods can narrow issuance to the challenge you intentionally operate. They add defense in depth; they do not secure a compromised DNS account, patch a vulnerable server, replace domain validation or protect an already-issued private key.

The operational cost is real. Account migration, disaster recovery, panel changes and a switch from HTTP to DNS validation all require a CAA review. Keep the owner, account URI, challenge method, rollback record and last successful test in the same runbook.

FAQs

Do I have to add accounturi before March 2027?

No. The CA/Browser Forum deadline applies to CA processing. Publishing the parameters remains optional for domain owners.

Can I use accounturi with cPanel AutoSSL?

Usually not safely unless your host gives you the exact account and guarantees it will remain stable. Shared hosting customers normally do not control the ACME account used by AutoSSL.

Does an empty CAA lookup mean anyone can get a certificate?

No. It means CAA adds no issuer restriction. A publicly trusted CA must still validate control of the domain and satisfy its other issuance rules.

Can one record contain both parameters?

Yes, when the CA supports them. Separate the parameters with semicolons and use the exact syntax documented by the CA.

Why can Certbot dry-run fail after account pinning?

The dry run uses Let's Encrypt staging, whose ACME accounts are separate from production. A production-only account URI can therefore reject the staging request by design.

What is the safest first deployment?

Use a non-critical hostname with its own renewal path, saved DNS rollback and someone available to inspect the result. Expand only after a successful issuance test.