Skip to main content
All fixes

SSL, TLS, security headers

Add CAA DNS records to control which CAs may issue certificates

Without a CAA record, any public CA can issue a certificate for your domain. Publish CAA records limiting issuance to your chosen CAs.

What's happening

CAA (Certification Authority Authorization, RFC 8659) is a DNS record type that tells public CAs which authorities are permitted to issue certificates for a domain. Without a CAA record, every public CA in the trust store is allowed to issue — and an attacker who compromises domain validation at any one of them can mint a certificate for your domain without your involvement.

Since September 2017, the CA/Browser Forum baseline requires every public CA to check CAA records before issuance. A CAA record listing only letsencrypt.org means DigiCert, Sectigo, GoDaddy, and every other CA must refuse to issue. The record is a defensive measure that adds little operational burden and a real layer of attack-surface reduction.

The fix is to publish CAA records on the apex domain that list every CA you actually use, plus a separate issuewild clause if you want to restrict who can issue wildcards, plus an iodef clause that tells violating CAs where to send incident reports.

Why it matters

An attacker who compromises domain validation at any CA can issue a certificate for your domain. Past incidents include the Comodo reseller breach (2011) and the WoSign/StartCom incidents (2016) that resulted in mass distrust. CAA is one of the cheapest mitigations.

Compliance frameworks (NIST 800-53 SC-12, CIS Controls v8) and bug-bounty programs accept missing-CAA as a finding. SSL Labs reports the presence/absence of CAA in its test results.

Without CAA, post-incident forensics is harder — you cannot tell from CT logs alone whether an issuance was legitimate or was an unauthorized minting.

Common causes

  • DNS provider does not support CAA records (rare in 2026 but still happens with older providers).
  • DNS migration dropped the CAA records and they were never re-added.
  • Domain owner is unaware CAA exists.
  • CAA records were added but list a CA the team no longer uses, blocking legitimate issuance.
  • CAA records exist but lack issuewild clauses, leaving wildcard issuance unrestricted.

Detect this on your site

Run a quick scan with the DNS Checker. The tool surfaces this exact issue with the records and context needed to apply the fix below.

Open DNS Checker

How to fix it

  1. 1

    Check whether CAA records exist

    Run dig CAA example.com +short. If nothing returns, no CAA records are published. Run dig CAA example.com +trace for full propagation visibility. The CheckFast DNS Checker at /dns also confirms presence.

  2. 2

    Decide which CAs you trust

    List every CA that legitimately issues for your domain. Common: letsencrypt.org, digicert.com, sectigo.com, amazonaws.com (for ACM), pki.goog (Google Trust Services), globalsign.com. Only list CAs you actually use; adding extras dilutes the benefit.

  3. 3

    Publish issue and issuewild records

    Add records like example.com. CAA 0 issue "letsencrypt.org" (allows non-wildcard issuance) and example.com. CAA 0 issuewild "letsencrypt.org" (allows wildcard issuance). Without an issuewild clause, no CA may issue a wildcard regardless of issue clauses.

  4. 4

    Add an iodef clause for incident reporting

    Add example.com. CAA 0 iodef "mailto:security@example.com". CAs that detect attempts to issue against your CAA policy will email this address. Even a few incidents per decade make the record worth publishing.

  5. 5

    Apply via your DNS provider

    In Cloudflare DNS, choose CAA, set Type to issue/issuewild/iodef and Value to the chosen CA or contact. In Route 53 use the CAA record type. Most providers support a UI form; some still need raw record syntax.

  6. 6

    Verify and re-issue if needed

    Re-run dig CAA example.com. Each record should appear. Issue a fresh test certificate from the listed CA to confirm issuance still works. If a CA is mistakenly omitted, the next renewal will fail — set monitoring on certbot logs.

Example

; Allow only Let's Encrypt for non-wildcard
example.com.    IN  CAA  0 issue "letsencrypt.org"
; Allow only Let's Encrypt for wildcard issuance
example.com.    IN  CAA  0 issuewild "letsencrypt.org"
; Send violation reports here
example.com.    IN  CAA  0 iodef "mailto:security@example.com"

CAA records constraining issuance to Let's Encrypt only

Frequently asked

CAs check CAA at issuance time only — not on every TLS handshake. New CAA records apply to future issuances. Existing certificates from now-disallowed CAs continue to work until expiry.

Only list ones you actively use. CAA is most effective when narrowly scoped. If you migrate CAs update the records as part of the migration runbook so the new CA can issue and the old one cannot.

No — every CA in the public trust store must respect CAA per CA/Browser Forum requirements. Let's Encrypt ZeroSSL DigiCert Sectigo and every other CA implement the same checks.

Related fixes

SSL, TLS, security headers

Limit wildcard SSL certificate scope to reduce blast radius

SSL, TLS, security headers

Verify SSL certificate appears in Certificate Transparency logs

SSL, TLS, security headers

Fix expired SSL certificate and restore HTTPS access

SSL, TLS, security headers

Renew SSL certificates before they expire and break HTTPS