How to Tell If Someone Issued an SSL Certificate for Your Domain

Certificates for your domain can be issued by parties other than you. Sometimes that's completely legitimate — a CDN provisioning one on your behalf, a platform issuing for a custom hostname, a colleague setting up a new service. Occasionally it isn't: a certificate obtained by someone who briefly controlled a DNS record, or issued in error by a certificate authority.

The good news is that you don't have to take anyone's word for it. Since 2018, browsers have required every publicly-trusted TLS certificate to be recorded in Certificate Transparency logs — public, append-only, and specifically designed so mis-issuance can be caught. The logs exist precisely so domain owners can audit what's been issued in their name.

What the logs contain

Every entry records the certificate, the issuing certificate authority, the hostnames it covers, and when it was issued. That's enough to answer the questions that matter: what exists, who signed it, and what it's valid for.

Two things they don't do. They don't tell you whether a certificate is legitimate — the log records fact, not intent. And they don't cover privately-issued certificates from an internal CA, which never enter the public system.

Checking what's out there

The quickest way to see the hostnames in your domain's log entries is our free subdomain finder — it queries Certificate Transparency for a domain and lists every subdomain that's appeared in a logged certificate, plus any wildcard certificates separately. It's passive; nothing is sent to your infrastructure.

For a first pass, what you're looking for is anything you can't account for:

• A hostname you don't recognize — vpn., mail., admin. prefixes you never provisioned.
• A certificate authority you don't use. If everything runs through one CA and something is signed by another, that's worth a question.
• A wildcard you didn't request. A *.example.com certificate is broad by definition; it should be deliberate.
• Issuance timing that doesn't line up with any deployment you did.

Telling routine from suspicious

Most unexpected entries have boring explanations, and it's worth knowing them so you don't chase every one:

• Renewals look like new issuance. A certificate renewed every 60–90 days produces a steady stream of log entries. That's normal automation, not activity.
• CDNs and platforms issue on your behalf. If you use a CDN, managed host, or SaaS with custom domains, certificates will appear from CAs you never chose. Expected.
• Pre-certificates are logged too. You may see what looks like a duplicate around the same timestamp — that's part of how the system works, not two certificates.

What genuinely deserves investigation is a certificate covering a hostname you don't operate at all, or one issued during a window when something else looked wrong — a nameserver change you didn't make, a registrar login you don't recognize. A certificate on its own is a weak signal; a certificate plus another anomaly is a strong one.

If the hostname is one you used to operate and abandoned, you may be looking at a different problem — see what is a subdomain takeover, where the exposure comes from a DNS record you left pointing at a service you no longer control.

Restricting who can issue: CAA

Checking after the fact is useful. Preventing issuance is better, and there's a DNS record for it: CAA (Certification Authority Authorization). It names the certificate authorities allowed to issue for your domain, and compliant CAs are required to check it and refuse if they're not listed.

Almost nobody sets one. With no CAA record, any public CA may issue for your domain to anyone who passes its validation checks. With one, you've cut the set of authorities that can be tricked down to the ones you actually use.

It's a short DNS record and a five-minute job. Our WHOIS & DNS lookup shows whether your domain currently has one — most don't.

Two caveats worth stating plainly: CAA constrains authorities, not attackers. Someone who controls your DNS can change the CAA record as easily as any other. And it only binds CAs that follow the rules. It raises the bar; it isn't a lock.

Why one-off checks don't catch this

The problem with auditing the logs manually is timing. A certificate issued the day after you look sits there unnoticed until your next audit — and the value of noticing a mis-issued certificate decays fast. Finding it in a day is an incident you contain. Finding it in six months is an incident you reconstruct.

That's what continuous monitoring is for. DomainChest watches Certificate Transparency logs for your domains. The first check simply records where you are, so you don't get a wall of alerts for your existing certificates. After that, every newly-logged certificate for the domain or its subdomains raises an alert naming the hostnames it covers and the issuing authority — so a certificate you didn't expect reaches you as a notification rather than a discovery.

It tracks the expiry side at the same time, including certificates on subdomains, which is the failure that takes a site down without any attacker involved. There's more on the SSL & certificate monitoring page — and if you just want to check one host's certificate right now, the free SSL certificate checker will tell you what it is and when it expires.