CAA Policy Explorer: Map Certificate Issuance Across Subdomains

Most organisations don’t have a good handle on their CAA records. They’re hard to audit, easy to misconfigure, and once you have more than a few subdomains, practically impossible to reason about as a whole.

We built the CAA Policy Explorer in SSLBoard to fix that. It gives you a single view of your Certificate Authority Authorization policy across every subdomain, built from Certificate Transparency logs and live DNS lookups.

What is a CAA record?

CAA (Certificate Authority Authorization) is a DNS record type defined in RFC 8659. It lets you declare which Certificate Authorities are allowed to issue TLS certificates for your domain.

It’s basically an allowlist in DNS. If your domain has a CAA record naming only letsencrypt.org, then DigiCert, Sectigo, and every other CA is blocked from issuing for that domain. Any CA that ignores your CAA record is in violation of the CA/Browser Forum Baseline Requirements.

CAA records support three property types:

• issue authorises a CA to issue standard certificates
• issuewild authorises a CA to issue wildcard certificates (takes precedence over issue for wildcard requests)
• iodef specifies an email or URL where the CA should report policy violations

When no CAA record is set, any CA can issue. That’s the default state for most organisations, and it’s a problem.

Why CAA records matter

A mis-issued certificate for your domain, issued by a CA you’ve never dealt with, gives an attacker what they need for a convincing phishing page or a man-in-the-middle attack. The browser shows a padlock. Your users see nothing wrong.

CAA records prevent that. The CA/Browser Forum required all CAs to perform CAA lookups before every issuance starting September 8, 2017. In 2024, Sectigo extended CAA enforcement to S/MIME certificates too.

The protection only works if your CAA records are actually correct, though. And getting them right across a large domain is harder than it sounds.

The problem with managing CAA at scale

For a domain with a handful of subdomains, setting up CAA records takes an afternoon. For an enterprise with dozens or hundreds of subdomains, each potentially using a different CA, a different team, and different infrastructure, it gets messy fast.

CAA records inherit downward through the DNS tree. A subdomain with no CAA record falls back to its parent, which falls back to its parent, all the way up to the apex domain. That sounds convenient until someone sets a CAA record on mail.example.com that accidentally blocks wildcard issuance for *.mail.example.com. You won’t notice unless you check each level individually.

The issue and issuewild tags are also separate controls. A domain that authorises DigiCert for standard certificates might still block it from issuing wildcards. A semicolon ; as the issuer value means no CA is permitted at all, which will silently block renewals.

And DNS tooling only shows you one record at a time. You can’t query “what is the effective CAA policy across all of my subdomains.” You’d have to enumerate every subdomain, walk up the DNS tree for each one, and interpret the inheritance rules manually.

Then there are the subdomains you don’t know about. Shadow IT, old deployments, acquired companies. Organisations regularly have subdomains with active certificates they’ve never audited, and you can’t set the right CAA policy for infrastructure you can’t see.

If you’ve ever searched Let’s Encrypt’s community forum for CAA errors, you know how common this is. AWS re:Post, DirectAdmin forums, and ZeroSSL’s help centre all have dedicated CAA troubleshooting articles. The errors are cryptic, the inheritance rules are non-obvious, and until now there hasn’t been a tool that shows the full picture.

How SSLBoard’s CAA Policy Explorer works

The CAA Policy Explorer does two things together that we haven’t seen combined anywhere else.

First, it builds a complete subdomain inventory from Certificate Transparency logs. Every TLS certificate ever issued is logged in the public CT infrastructure. SSLBoard indexes these logs continuously, so when you query a domain, we already know every subdomain that has ever had a certificate issued for it. That includes subdomains your team has forgotten about, acquired domains, and staging environments that never made it into internal documentation.

Second, it performs live DNS lookups for each of those subdomains, retrieving CAA records at the subdomain level and at each parent level. It models the exact inheritance chain that a CA would follow at the moment of issuance.

The result is a policy table showing, for every subdomain, which CAs are authorised to issue standard certificates (ISSUER) and which are authorised to issue wildcards (WILD ISSUER).

What the BambooHR example shows

The screenshot above shows the CAA Policy Explorer for bamboohr.com with 9 subdomains. A few things stand out:

• email.community.bamboohr.com has issuewild set to ; , digicert.com. The leading semicolon is a deliberate block on all CAs, followed by only DigiCert being authorised. A valid but unusual pattern.
• insights.bamboohr.com has a wild issuer of just ;, meaning no CA is authorised to issue wildcards for that subdomain. Any wildcard certificate request will fail.
• hello.bamboohr.com and corpstatus.bamboohr.com have None for wild issuer, so the policy relies entirely on inheritance from the parent domain.
• r.hr.bamboohr.com authorises five different CAs for standard issuance: comodoca.com, digicert.com, entrust.net, globalsign.com, letsencrypt.org, and pki.goog. That suggests multiple teams or systems are handling TLS for that subdomain.

Any of these could be intentional or could be a misconfiguration waiting to break a renewal.

Try it

We haven’t found another tool that does this. The CAA tools we’ve seen from DNS providers, CA vendors, and security scanners all operate on a single domain at a time. None of them combine a CT-derived subdomain inventory with a full CAA policy tree view.

The CAA Policy Explorer is available now in every SSLBoard report. Run a report on your domain and look for the CAA Policies section under the DNS analysis tab.