Certificates, CAA and Certificate Transparency

1 Introduction

Your TLS configuration covers the certificate your server shows today. But dozens of public certificate authorities (CAs) can issue a certificate for your domain, and every one they issue is recorded in public logs. That gives you two questions to answer as the owner: who is allowed to issue certificates for my domain, and what has actually been issued?

CAA answers the first: a DNS record that lists the authorities you use. Certificate Transparency answers the second: append-only logs where every publicly trusted certificate must appear. The Certificates section of a domain scan reads both, builds your certificate history, and points out certificates you share with other domains.

2017

Year checking CAA before issuance became mandatory for every public CA

RFC 8659

The current CAA standard (2019), replacing RFC 6844

Public

Every name on every trusted certificate can be searched by anyone, including attackers

2 How It Works

A certificate goes through three steps before a browser accepts it. CAA acts before issuance, Certificate Transparency after it.

Prove control

The requester proves control of the domain to the CA (a file on the website, a DNS record under _acme-challenge, or an email).

Check CAA

The CA looks up your CAA record. If one exists and does not name this CA, it must refuse.

Log it

The CA submits the certificate to public CT logs. Browsers such as Chrome and Safari reject certificates that were not logged.

Prevent, then detect

CAA narrows the number of authorities an attacker could fool or compromise from dozens down to the one or two you actually use. CT does not block anything, but it means a rogue certificate for your domain cannot stay secret: it shows up in the logs, where you (or a monitoring service) can see it. Neither replaces the other, and both cost nothing.

3 Detailed Analysis

CAA: who may issue for you

One or more CAA records on the domain itself. They also apply to every subdomain that has no CAA of its own:

example.com.  CAA  0 issue     "letsencrypt.org"
example.com.  CAA  0 issuewild ";"
example.com.  CAA  0 iodef     "mailto:[email protected]"

issue and issuewild

issue lists the CAs allowed to issue normal certificates. issuewild does the same for wildcards (*.example.com); without it, wildcards follow issue. The value ";" means "nobody". The example above allows Let's Encrypt for normal certificates and forbids wildcards entirely.

iodef: who gets told

An address where a CA can report a refused request. Support among CAs is uneven, so treat it as a bonus. The scan notes its absence as information only.

Find the right identifier

Each CA documents the domain to put in the record: letsencrypt.org, pki.goog (Google Trust Services), digicert.com, sectigo.com, and so on. CDNs and hosting platforms often issue through one or more CAs on your behalf; check their documentation before restricting.

In the report, the CAA block shows:

CAA record: Absent

Any public CA may issue for your domain. The scan flags it as medium severity. Publishing a record is a five-minute change in your DNS panel.

Issuance matches CAA, and the "Authorities that actually issued" table

The scan compares the CAs behind your currently valid certificates with your record. Not in CAA means a CA issued a certificate that your record does not allow today. Most often the record was added after the certificate, or a provider you forgot uses another CA. Find out which, then either add that CA or revoke and replace the certificate.

ACME validation (_acme-challenge)

A CNAME on _acme-challenge delegates certificate validation to another party (a CDN, a DNS automation service). That party can obtain certificates for your domain, and CAA does not stop it: CAA limits which CA signs, not who proves control. If the scan says target zone missing, the delegation points to a domain that no longer exists, and whoever registers it can get certificates for you. Delete that record now. Leftover _acme-challenge TXT tokens ("stale tokens") are harmless but can be removed.

Certificate history

Built from Certificate Transparency, this block reads your past certificates as a timeline. The chips give HTTPS since (age of the oldest certificate seen), the number of Certificates and Authorities, the Median renewal interval, how many are Valid today, and whether a Wildcard exists.

A new authority started issuing

The yellow banner appears when a CA you did not use before starts issuing while another one is already in place. After a move to a new host or CDN, that is expected. If nobody on your side changed anything, find out who requested the certificate.

Valid wildcard names

A wildcard certificate covers every subdomain at that level. Its private key is worth more than any single-name key, and it often ends up copied to many servers. Know where each one lives, and prefer per-service certificates when automation makes them free.

Many certificates valid at once, or a very short renewal interval

Several platforms (CDN, mail, staging) each holding their own certificate is normal. A tool that requests a new certificate every day, or dozens of certificates valid at the same time for one name, usually means a renewal loop to fix. "Log duplicates merged" is not an issue: a precertificate and its final certificate are logged separately and counted once.

Shared certificates

A single certificate can list many names in its Subject Alternative Name field. When some of those names belong to other, unrelated domains, the scan marks the certificate Shared and counts the co-signed domains. These are not your subdomains: they are other customers of the same platform.

Why it happens

Some CDNs, shared hosts and website builders put many customers on one certificate to save on certificates or IP addresses. It is a sign of multi-tenant hosting, not of a compromise.

Why it matters

You do not control the key: whoever holds it can serve any name on the list. Anyone reading the certificate also learns who your neighbours are, and investigators use those lists to link domains together. For a brand site, a login page or anything handling customer data, ask your provider for a dedicated certificate (often a setting or a plan option) or use your own.

Certificate Transparency logs

CT logs (RFC 6962) are public, append-only records of issued certificates. You can search them yourself on crt.sh: enter %.example.com to see every certificate for your domain and its subdomains.

Use it to catch rogue certificates

Several free services (some CAs, some CDNs, open-source tools) email you when a new certificate for your domain is logged. Turn one on: it is the only way to learn quickly that someone obtained a certificate in your name.

Everything in it is public, forever

Names such as vpn-test.example.com or jira-old.example.com stay readable after the service is gone. Attackers enumerate subdomains this way. Names that no longer resolve are covered in subdomain takeover. For internal-only hosts, use a private CA or a wildcard rather than logging each name.

You cannot remove an entry

If a certificate was issued by mistake, revoke it with the CA. It stays in the log, but it is marked revoked and no longer trusted by clients that check.

What to fix first

Urgent: an _acme-challenge delegation to a zone that no longer exists, or a certificate you cannot explain.

Important: publish a CAA record listing the CAs your certificates actually come from (the scan's "Authorities that actually issued" table gives you the list).

Hygiene: turn on CT monitoring, move sensitive sites off shared certificates, and add iodef.

Check your domain on mlab.sh

A domain scan reads your CAA record, compares it with the authorities that actually issued for you, rebuilds your certificate history from Certificate Transparency, and flags shared certificates.

Scan your domain on mlab.sh

4 Red Flags

_acme-challenge delegated to a zone that no longer exists

Whoever registers that zone can prove control of your domain and get valid certificates for it. Remove the CNAME today.

A certificate from an authority nobody on your team chose

A "new authority" banner or a "Not in CAA" verdict with no migration behind it. Find the requester before assuming it is harmless.

No CAA record

Every public CA can issue for you, so the weakest one sets your security level. Restrict it to the one or two you use.

Your login or payment site on a shared certificate

A key you do not control covers your name next to unrelated sites. Ask for a dedicated certificate.

Internal hostnames in CT logs

Admin panels, staging or VPN names published in a public certificate hand an attacker a target list. Use a private CA for what should stay internal.

Related Modules

TLS configuration explained

Protocol versions, cipher suites and certificate validity: what a TLS scan result means and how to fix a weak configuration.

Your attack surface: subdomains

What subdomain enumeration reveals to an attacker, and how to shrink the surface: forgotten hosts, staging, admin panels.

Subdomain takeover and dangling DNS

How a forgotten CNAME or NS record lets anyone serve content on your subdomain, and how to find and clean up dangling DNS before an attacker does.