How to Control Who Can Issue Certificates for Your Domain

Any publicly trusted certificate authority can, in principle, issue a certificate for your domain. Two mechanisms narrow that down. A CAA record in your DNS lists the CAs you allow, and every CA must check it before issuing. Certificate Transparency (CT) logs record the certificates that were actually issued, in public, so you can check the outcome. One is the rule and the other is the receipt.

We have separate explainers on how CAA records and Certificate Transparency work. This guide is the practical half: how to put the pair in place on a real domain, and what to do on the day the logs show a certificate nobody on your side asked for.

The order matters. Most advice starts with writing the CAA record. Start with the logs instead, because a CAA record written from memory is the most common way people block their own certificate renewals.

Start with an inventory, not a policy#

Before you can say which CAs are allowed, you need to know which ones you already depend on. Your own memory is a poor source for that. The web server's certificate is easy to remember. The help desk on support.example.com, the status page, the marketing landing pages and the staging box someone set up last year are not, and each of them may get its certificates from a different CA.

Search your apex domain in our Certificate Transparency search. It lists the certificates logged for the domain and its subdomains, newest first, along with a count of how many came from each issuer. Work through that issuer list and, for each one, find out who requested those certificates:

• Your own servers, usually through an ACME client such as Certbot renewing on a schedule.
• Your CDN or hosting platform, which may issue on your behalf without you ever seeing the request.
• Third-party services serving a subdomain you pointed at them: help desks, email marketing tools, website builders.
• Things nobody remembers. These are worth chasing down before you write any policy, because an unknown issuer is either a forgotten service or an early warning.

Pay attention to recent history, not only to certificates that are valid today. A CA that issued a certificate four months ago for a service that renews automatically is still in use, even if that certificate has since been replaced. Note also which issuers appear only on wildcard certificates (names starting *.), because CAA treats wildcards separately.

Finally, translate each issuer into its CAA identifier. CT results show the CA's organisation name, but a CAA record needs the issuer domain name that the CA publishes in section 4.2 of its certificate policy or practice statement. Let's Encrypt is letsencrypt.org, Google Trust Services is pki.goog, Sectigo is sectigo.com and SSL.com is ssl.com. For anything else, look the value up in the CA's own documentation rather than guessing; a wrong identifier silently blocks that CA.

Turning the inventory into CAA records#

Suppose the inventory found two CAs, neither of them used for wildcards. The policy looks like this:

example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issue "pki.goog"
example.com. CAA 0 issuewild ";"
example.com. CAA 0 iodef "mailto:security@example.com"

Each issue line authorises one CA. The issuewild ";" line names no CA at all, which means no CA may issue a wildcard. Once any issuewild record is present it alone decides wildcard requests, and the issue lines are ignored for them (RFC 8659, section 4.3). If you do use wildcards, put the CA that issues them in issuewild instead of the semicolon.

Where you publish matters. A CA looks for CAA records at the exact name in the certificate, then climbs one label at a time towards the top-level domain and uses the first set it finds. Records at the apex therefore cover every subdomain. But a subdomain that has CAA records of its own replaces the apex policy for that branch rather than adding to it, so its records must repeat every CA it still needs.

CNAMEs change the answer. When a hostname is a CNAME to a provider, the CA's DNS lookup follows the alias, and if the target publishes CAA records those are what the CA sees for your hostname. That is a frequent surprise with subdomains pointed at SaaS products: the provider's policy, not yours, may decide who can issue for them.

The iodef line asks CAs to report refused requests to an address you choose. It is worth adding, but the CA/Browser Forum's Baseline Requirements do not oblige CAs to act on it, so treat any reports as a bonus rather than as your alarm system. CT is the alarm system.

Pinning issuance to your own account#

A plain issue "letsencrypt.org" line allows anyone who can pass Let's Encrypt's domain validation for your name to get a certificate. Usually that is only you. But someone who can put a file on a web server answering for one of your hostnames, or who briefly controls a dangling subdomain, can pass HTTP-based validation too.

RFC 8657 adds two parameters that tighten this. accounturi limits issuance to one specific account at the CA, and validationmethods limits which validation methods the CA may use:

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

With that record, Let's Encrypt should only issue to the ACME account with that ID, and only after a DNS-based challenge. Let's Encrypt documents support for both parameters and accepts http-01, dns-01 and tls-alpn-01 as method names.

Two cautions before you use them. First, support is up to each CA today. The Baseline Requirements say CAs should process these parameters now and make it a requirement from 15 March 2027, and the RFC itself warns domain owners not to assume the restriction works unless the CA documents support for it. Second, account binding is brittle. A new server or a fresh install of your ACME client usually registers a new account, and renewals from it will then be refused by your own record. Back up the account key, or add a separate issue line for each account you run.

Our CAA lookup shows the raw records exactly as published, parameters included, alongside a summary of which CAs are authorised for ordinary and wildcard certificates.

Managed certificates and CAs you did not pick#

If a CDN or hosting platform manages your certificates, it chooses the CA, and it may switch CAs between renewals. Your CT inventory shows who issued last time, not who the platform might use next time. Check the provider's documentation for the full list of CAs it needs in your CAA records.

Cloudflare is a useful example of how this can work in your favour and against your expectations at once. For Universal SSL, Cloudflare automatically adds CAA records for the CAs it uses as soon as you add any CAA record of your own. Those records do not appear in the dashboard, although a dig example.com caa query shows them. Cloudflare notes that the CA list can change for operational reasons, and that the automatic records do not apply to Advanced Certificate Manager, where adding the right values is your job.

Rolling it out without breaking renewals#

CAs consult CAA only when issuing. Certificates already in service keep working, which is reassuring but also means a mistake stays hidden until the next renewal, possibly weeks away. A few habits keep that from becoming an outage:

• Check what CAs will see. After publishing, run your apex and a few important subdomains through the CAA lookup. It shows where in the hierarchy the records were found, so you can spot a subdomain overriding the apex.
• Force a renewal early. Renew one certificate from each issuer in your inventory on purpose, while you are watching, instead of waiting for the scheduled run.
• Expect a delay. A CA may issue up to eight hours after it last checked your CAA records, or longer if the record's TTL is longer. A record you just tightened is not binding the instant you save it.
• Mind DNSSEC. If your zone is signed, a broken signature makes CAA lookups fail, and the Baseline Requirements forbid treating a DNSSEC validation error as permission to issue. Broken DNSSEC therefore blocks every CA, including yours. The DNSSEC validator will show the problem.
• Make CAA part of onboarding. When someone adds a new service that will issue certificates for one of your names, the CAA record needs updating first.

When CT shows a certificate you did not expect#

Most surprises have an innocent explanation, so confirm before escalating. Read the certificate's name list, issuer and dates. A certificate for support.example.com from a CA you do not use often turns out to belong to a help desk vendor someone signed up for.

If it really is unauthorised, work through it in this order:

• Report it to the issuing CA. Every CA must accept Certificate Problem Reports around the clock, investigate within 24 hours and send a preliminary report. Where the domain validation should not be relied on, including issuance your CAA record did not permit, the CA must revoke within 24 hours. The CA's practice statement explains how to file.
• Revoke it yourself if the CA uses ACME. Under RFC 8555, an ACME account that holds validated authorisations for every name in the certificate may request its revocation. Prove control of the names with that CA, then revoke.
• Find out how it happened. Revocation removes the certificate, not the cause. Look for a leaked DNS provider credential, a dangling CNAME someone has taken over, or write access to a server answering for the name.

Periodic manual searches suit audits. For continuous coverage, a CT monitoring service can alert you when a new certificate for your domain appears, so you hear about it within hours instead of at the next review.

What this setup cannot stop#

It helps to be clear about the limits. CAA binds CAs that follow the rules; a CA that ignored it would still be caught, but by CT after the fact, not prevented. Anyone who controls your DNS can edit your CAA record as easily as any other record, so the accounts at your DNS host and registrar deserve the same protection as the servers. CAA does nothing to certificates already issued. And CT covers publicly trusted certificates only, so certificates from a private CA, such as one used for corporate TLS inspection, will not appear in the logs at all.

Within those limits, the pair does its job well. The inventory tells you what you depend on, CAA turns that into a rule every public CA must check, and CT lets you confirm the rule held. Repeat the inventory whenever you add a service, and the policy stays accurate.