Your domain probably lets any CA issue a certificate for it
Last Thursday I ran a CAA lookup on four of my own domains: uno.directory, indiehunt.io, auraplusplus.com and earlyhunt.com. All four came back empty. No CAA record at all. I ran it again this morning, Nov 2, and it’s still the same.
That means any public certificate authority is allowed to issue an SSL certificate for those names, as long as it thinks it validated that I control the domain. Not just Let’s Encrypt, which is the one we actually use. Any of them.
I don’t think that makes me unusual. Most small sites I’ve looked at have no CAA record, because nobody tells you about it. Your host gives you HTTPS automatically, the padlock shows up, and you never think about who else is allowed to make a cert for your name.
So this is the short version of what CAA is, how to check yours, and the record you probably want. I haven’t added it to my own domains yet as I write this, so I’m not going to pretend I have. This is the checklist I’m going to follow.
What a CAA record actually does
CAA stands for Certification Authority Authorization. It’s a DNS record where you list which CAs are allowed to issue certificates for your domain. The current rules are in RFC 8659, and public CAs have been required to check it before issuing since 2017.
Without one, the default is “everyone”. Let’s Encrypt’s own docs put it plainly: by default every public CA can issue for any domain, provided they validate control of it. So if any single CA has a bug in its validation, every domain without CAA is exposed to that bug.
With a record like this, you’re saying only Let’s Encrypt may issue:
example.com. CAA 0 issue "letsencrypt.org"The 0 is the flags field, and you’ll almost always leave it at 0. “issue” is the tag. The value is the CA’s identifying domain. A CA that isn’t on the list is supposed to refuse.
What “done” looks like on big sites
I looked up a few sites I trust, using Google’s public DNS, on Oct 30, and checked them again on Nov 2. Same answers.
google.com publishes exactly one record: issue “pki.goog”. Google only lets its own CA issue for it. Simple.
github.com publishes seven. For normal certs (issue) it allows DigiCert, Sectigo, Let’s Encrypt and GlobalSign. For wildcard certs (issuewild) it allows DigiCert, Sectigo and Let’s Encrypt. So GlobalSign can issue a cert for github.com, but not for *.github.com. That’s the detail most people miss: issue and issuewild are separate permissions, and if issuewild exists it wins for wildcards.
medium.com does something similar. Let’s Encrypt is on its issue list but not on its issuewild list, so Let’s Encrypt can’t issue a wildcard for it.
And for comparison, dev.to had no CAA record when I checked. Big sites skip it too. It’s not a sign of a broken site, it’s just an open door nobody closed.
How to check yours in a minute
If you have a terminal:
dig example.com CAA +shortEmpty output means no record, so any CA can issue. If you’d rather not read raw records, I built a free CAA record checker on Uno Directory. It’s one of my sites, so take that into account. You type a domain, and it tells you in plain words which CAs can issue for the name and for a wildcard of it. It also walks up to the parent domain when the name you typed has no record, because that’s how CAs do it too. It only does a DNS lookup, nothing else.
Get Praneet Brar’s stories in your inbox
Join Medium for free to get updates from this writer.
Next, find out which CA you actually use today. Open your site, click the padlock and look at the issuer, or run:
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -issuerAll four of my domains came back as Let’s Encrypt. Do this for every subdomain that serves something (app, api, docs, status), because different parts of your stack might use different CAs without you knowing.
Adding the record without breaking your HTTPS
This is the part where people get burned, so go slowly.
1. Put it on the root domain
CAs look for the record on the exact name first, then walk up one label at a time until they find one. So a record on example.com covers www.example.com, app.example.com and so on, unless a subdomain has its own record that overrides it.
2. List every CA you really use
If your marketing site is on Let’s Encrypt but your docs tool or status page is hosted somewhere that uses a different CA, and you only list letsencrypt.org, that other service fails at its next renewal. Records are additive, so just add one issue line per CA.
3. Watch out for Cloudflare and CNAMEs
If you’re on Cloudflare with Universal SSL, Cloudflare’s docs say it adds CAA records for its own partner CAs automatically once you add any CAA record, and those auto-added ones don’t show in the dashboard. Check with dig after you save.
CNAMEs matter too. If docs.example.com is a CNAME to some provider’s hostname, CAA checking follows the CNAME, so the provider’s CAA rules apply. Usually fine, just know that’s where to look if a cert suddenly won’t renew.
4. Lock down parked domains completely
This one is free and I like it most. Indie hackers collect domains. If a domain doesn’t serve any site, you can say no CA may issue for it at all:
parked-idea.com. CAA 0 issue ";"An issue tag with no CA name means “no issuance”. Nobody gets a valid cert for a domain you forgot you owned. I wrote about the other side of forgotten domains, the old CNAMEs that point at things you don’t own anymore, and it’s worth doing both on the same afternoon.
5. Re-check after saving
Run the dig command again, or the checker, and make sure the answer matches what you meant. Then wait for your next renewal and confirm it went through. If you renew automatically, you might as well check your renewal setup at the same time, since certificate lifetimes are getting shorter. Let’s Encrypt is moving to 64-day certificates, so a renewal job that quietly broke will show up faster than it used to.
What CAA doesn’t do
I want to be honest about the limits, because people oversell this.
CAA is checked by the CA at the moment it issues. It does nothing to certificates that already exist. It doesn’t stop a CA you allowed from making a mistake. And it depends on CAs following the rules, which public CAs are required to do, but it’s still a request, not a lock on your server.
If someone takes over your DNS, they can just change the CAA record. That’s what the optional accounturi parameter is for: it ties issuance to your specific ACME account, so even a person who can pass domain validation can’t get a cert without your account key. Let’s Encrypt supports it. For most small sites the plain issue record is enough to start. The bigger lesson is that your registrar login matters more than any record in it. I put registrar lock and the other account lockout checks in a separate checklist.
It also doesn’t replace watching for certificates. Certificate Transparency logs record publicly trusted certs, and you can search them on crt.sh to see every cert issued for your domain. CAA reduces who can issue. CT shows you what was issued.
The whole thing, short
Look up your CAA record. Find which CAs you actually use, on every subdomain. Add one issue line per CA on the root domain. Add issue “;” on every parked domain. Check again after saving and after the next renewal.
It’s maybe fifteen minutes for a handful of domains. I’m doing mine this week. If you want to check yours first, the Uno CAA checker is free and needs no signup.
Curious if anyone here has actually had a CAA record break a renewal. Was it a CNAME, Cloudflare, or a service you forgot was issuing certs for you?
