DNS SecurityCAAACMEcertificate policy

CAA Record Checker/Generator

Check and generate CAA issue, issuewild, iodef, ACME account bindings, validation methods, and issuemail tags.

Use it before changing certificate-authority authorization policy for a domain.

Inputs

CAA Record Checker/Generator is one of 24 directly executable, read-only WebMCP diagnostics registered on the root page. It returns a structured result using the same canonical description in document.modelContext, tool pages, tools.json, well-known manifests, OpenAPI, and JSON-LD.

Example

example.com -> issue letsencrypt.org; issuewild ; iodef mailto:hostmaster@example.com; validationmethods dns-01.

Deciding who may issue certificates for your name

Any publicly trusted certificate authority can, in principle, issue a certificate for your domain — unless you say otherwise. CAA is where you say otherwise: a DNS record the CA must check at issuance time, naming the authorities you authorize. It is the control that turns a mis-issuance from an open possibility into a policy violation with an audit trail, and it is the control that catches the well-meaning colleague ordering a certificate from a vendor your PKI strategy retired two years ago.

The record's grammar is small but exact. The issue tag authorizes a CA for host certificates, issuewild separately governs wildcards, and iodef names a reporting address for policy violations. RFC 8657 adds sharper pins for ACME: accounturi restricts issuance to one specific ACME account, and validationmethods restricts which challenge types are acceptable. This tool validates existing records — pasted or fetched live — and drafts a conservative policy when none exists yet.

Auditing and drafting CAA policy

For an audit, run the live lookup and read issue and issuewild first: they carry the actual authorization. Remember the lookup semantics — a CA starts at the requested name, follows aliases as required, and climbs parent by parent until it finds the first relevant CAA RRset. A CAA RRset on a child name therefore applies to that exact name and descendant names that do not publish a closer RRset; it does not universally replace the apex policy. An empty issuer value denies issuance.

When drafting, authorize exactly the CAs you use, and check the operational path before you publish: your certificate automation must still succeed after the record goes live, and adding a CA must become a documented step of any future vendor change — CAA-caused renewal failures surface weeks later, at the worst possible moment, as expired certificates. If you operate ACME at scale, accounturi is the strongest cheap upgrade, because a stolen domain validation no longer suffices without your account key.

Issuance-time policy, not certificate inventory

Pasted records stay in the browser. Live lookups use DNS-over-HTTPS first with a same-origin fallback, and RFC 3597 generic wire-format answers are decoded before validation. The tool judges record syntax and policy coherence at lookup time. It cannot see what any CA actually logged at issuance, does not scan Certificate Transparency for certificates that predate or violate your policy, and cannot verify that a CA honors iodef reports. Pair a CAA policy with CT monitoring for the full picture.

Frequently asked questions

Does publishing CAA invalidate certificates that already exist?

No. CAA is evaluated only at issuance. Existing certificates run to their natural expiry regardless of policy changes — which also means CAA is not a revocation tool; it only shapes the future.

Which CAA set applies to a name several labels deep?

The first relevant RRset found by RFC 8659 discovery: start at the requested name, follow aliases where required, then climb parent by parent. A child RRset applies to that name and descendants without a closer RRset; sibling names and the apex keep their own discovery paths.

What happens if issuewild is absent?

Wildcard issuance then follows the issue tags. Publish issuewild only when wildcard policy should differ — for instance, allowing host certificates broadly while forbidding wildcards entirely.

What does accounturi actually protect against?

Issuance by the right CA but the wrong hands. With accounturi, the CA additionally requires the request to come from your named ACME account, so an attacker who can pass domain validation still fails without your account key.

Is iodef worth setting?

Set it — an address that receives violation reports costs nothing and occasionally catches a misconfiguration early. But treat it as best-effort: reporting behavior varies between CAs, so it complements CT monitoring rather than replacing it.

Can CAA break my own renewals?

Yes, and that is the most common self-inflicted CAA incident: switching CA vendors without updating the record. The old certificates keep working, the first renewal through the new CA fails, and the failure surfaces as an expiry alert weeks later.