CT Alert in Your Inbox? How to Read It Before You Panic

An email just told you a TLS certificate was issued for your domain, and your stomach dropped. In most cases, this is nothing to worry about: it's almost certainly a certificate you, your host, or a service you use requested. A Certificate Transparency (CT) alert is a receipt, not an alarm — it fires every time any certificate is logged for your name, legitimate or not.

The job in front of you is simple: match the alert against what you already run. If you can account for the issuer, the hostname, and the timing, you can close the tab. If you can't, you have a lead worth chasing. This guide walks you through that check in order.

Why this matters right now: Cloudflare just moved its Certificate Transparency Monitoring to general availability, which means a lot more domain owners are suddenly getting these emails for the first time. If you've never seen one before and one landed this week, that's probably why.

What a Certificate Transparency alert actually tells you

A CT alert tells you that a certificate authority logged a certificate for one of your domains in a public, append-only log — nothing more. Since 2018, browsers like Chrome won't trust a publicly issued certificate unless it appears in these logs, so every CA that issues for your domain is required to publish a record. Monitoring services (Cloudflare, Google's own tools, and others) watch those logs for your name and email you when a match shows up.

The key thing to internalise: the log records issuance, not authorisation. A CA is supposed to verify control of the domain before issuing, but the log itself makes no promise that the request came from you. That's the whole point of transparency — it lets you catch a certificate you didn't ask for, which is the early warning sign of a phishing or impersonation setup.

So an alert is a prompt to answer one question: did I, or something acting on my behalf, cause this? Most of the time the answer is yes, and it's boring. The boring ones are the goal.

The 60-second triage: three fields that settle most cases

Open the alert and read three things — the issuer, the exact hostname, and the timestamp — and you'll resolve the vast majority of alerts without touching anything else.

• Issuer (the CA). Is it Let's Encrypt, Google Trust Services, DigiCert, Sectigo, or Amazon? These are the usual suspects behind legitimate certs. If your host auto-provisions SSL, the issuer will often be Let's Encrypt or Google Trust Services. An issuer you've never heard of deserves a second look, but an unfamiliar name alone isn't proof of anything.
• Exact hostname. Read it character by character. shop.yourdomain.com issued the day you launched a store subdomain is expected. A wildcard *.yourdomain.com you don't remember requesting is worth explaining. And watch for look-alikes in other domains — if you also monitor for typosquats, yourd0main.com is a different beast entirely.
• Timestamp. Line it up with your own activity. Did you add a domain to a CDN, spin up a new subdomain, renew hosting, or point DNS somewhere new in the last day or two? Certs renew on schedules too — Let's Encrypt certs typically reissue every 60 days, so a quiet renewal is routine.

If all three line up with something you did or something your host does on autopilot, you're done. File it and move on.

How to tell a legitimate cert from an impersonation attempt

A legitimate certificate traces back to infrastructure you control; an impersonation attempt points at servers, DNS, or accounts you don't. The difference is rarely in the alert email — it's in where the certificate ends up being used.

Work down this list in order. Stop as soon as you can account for the cert.

• Check your own CAA record. Run dig CAA yourdomain.com +short. If you've set a CAA record restricting issuance to, say, letsencrypt.org, then a cert from another CA is a genuine anomaly worth investigating. No CAA record means any CA could have issued it legitimately.
• Match it to your providers. List everyone who can request a cert for you: your web host, CDN, email provider, a load balancer, a marketing/landing-page tool, a status-page service. Each of these commonly provisions certs automatically. One of them is usually the answer.
• Look up where the hostname resolves. Run dig +short thehostname.yourdomain.com. If it points to your own IPs or your known CDN, relax. If it points at an IP you don't recognise, that's your signal to dig deeper.
• Inspect the live cert. If the hostname is reachable, check what's actually being served: echo | openssl s_client -connect thehostname.yourdomain.com:443 -servername thehostname.yourdomain.com 2>/dev/null | openssl x509 -noout -issuer -subject -dates. Compare the fingerprint and issuer to the alert.
• Search the CT logs yourself. Enter your domain at crt.sh to see the full history of certificates issued for your name. Patterns jump out here — a steady cadence of Let's Encrypt renewals looks very different from a one-off cert from an unknown CA for a subdomain you never created.

The scenario you're actually hunting for: a certificate for a hostname under your domain, issued by a CA you don't use, resolving to an IP that isn't yours. That combination suggests someone has gained control of a DNS record (a dangling subdomain is the classic route) and is standing up a convincing fake. That's the one you escalate.

What to do if the certificate is not yours

If you've ruled out every provider and the cert still doesn't add up, treat it as a possible domain or DNS compromise and act on both fronts at once. Don't wait to be certain — the cost of checking is low, the cost of a live phishing page on your brand is not.

Here's the order of operations:

• Audit your DNS. Log into your registrar and DNS host and review every record. Look for subdomains you didn't create and any recently changed records. Dangling CNAMEs pointing at decommissioned cloud services are the most common way attackers claim a subdomain and get a valid cert for it.
• Lock down the accounts that control issuance. Change passwords and enable two-factor on your registrar, DNS, hosting, and CDN accounts. A mis-issued cert often means one of these was accessed.
• Set a CAA record. Add one restricting issuance to the CAs you actually use. It won't undo a past cert, but it closes the door on future unauthorised ones from other CAs: yourdomain.com. IN CAA 0 issue "letsencrypt.org".
• Report it to the issuing CA. Every CA has an abuse/revocation channel. Give them the certificate's serial number (visible in the CT log entry) and ask them to investigate and revoke if mis-issued.
• Remove the dangling record. If a stale subdomain was the entry point, delete or repoint it so it can't be re-claimed.

If you host with us, this is exactly the kind of thing to bring to our chat — the AI is there at any hour to help you read the alert and run the checks, and real engineers follow up during business hours if it turns into something that needs a human. You don't have to decode a CT log alone at 2am.

Why you got the alert now (and how to keep the signal clean)

Most people seeing their first CT alert this month got it because Cloudflare's monitoring went generally available and started notifying every domain owner on its platform. The logs haven't changed; the number of people watching them just went up.

That's a net good — more eyes on issuance means impersonation gets caught faster. The risk is alert fatigue: if every routine renewal pings your inbox, you'll start ignoring them, and the one that matters slips through. A little tuning keeps the signal clean.

A good habit: keep a short note of which CAs your stack legitimately uses and on what cadence. When an alert arrives, you compare it to the list in seconds instead of starting from zero. Pair that with a CAA record and you've turned a scary inbox surprise into a routine ten-second check.

FAQ