Monitor Certificate Transparency Logs for Rogue SSL Certificates

Since 2018, every Certificate Authority is required to submit every SSL certificate it issues to public Certificate Transparency logs—a transparency initiative led by Google to prevent unauthorized certificate issuance from flying under the radar. While this creates a powerful security benefit, it also means attackers can see exactly which certificates have been issued for your domain. Certificate Transparency (CT) monitoring is the practice of watching these public logs to detect any suspicious or unauthorized certificates issued for your domain and taking action before they cause harm. This article explains what CT logs are, why they matter, and how to set up monitoring to protect your domain.

Understanding Certificate Transparency

Certificate Transparency is a system designed to make certificate issuance transparent and auditable. The core concept: every SSL certificate issued by any CA must be logged in at least two separate, independent public CT logs. This logging is mandatory—there's no way to issue a valid certificate that browsers will trust without proving it's in a CT log. Modern browsers like Chrome, Firefox, and Safari all verify that certificates contain Signed Certificate Timestamps (SCTs) proving they're logged before they'll accept them as valid. This creates a permanent, public audit trail of all certificate activity on the internet.

The system is designed to catch compromised or rogue Certificate Authorities. If an attacker tricks a CA into issuing a fraudulent certificate, or if a CA is actually compromised, the certificate must still go into CT logs. Even though the attacker can hide a lot of things in an attack, they cannot hide a certificate from the CT log requirement—it's built into the browser trust model itself.

Why CT Monitoring Is Critical for Security

Most domain owners only discover a problem with their SSL certificates when something breaks—users report getting security warnings, or an attacker uses the fraudulent certificate to launch a successful phishing campaign or man-in-the-middle attack. By then, the damage is already done. With CT monitoring, you learn about new certificates within hours of issuance, giving you time to investigate and revoke any that you didn't authorize.

Real-world scenarios where CT monitoring saves the day: A CA you trust gets compromised for a few hours—during that window, an attacker obtains a certificate for your domain. A disgruntled employee with CA account access issues a rogue cert. An attacker briefly hijacks your DNS and convinces a CA to issue a certificate (yes, some CAs are susceptible to DNS-based validation attacks). In all these cases, CT monitoring is your early warning system.

Searching Certificate Transparency Logs with crt.sh

The easiest way to manually check CT logs is crt.sh, a free service run by Sectigo. Here's how to use it: Go to https://crt.sh in your browser. Type your domain name in the search box (e.g., example.com). The site returns a complete list of all certificates ever issued for that domain, along with the issuance date, expiry date, CA name, and all Subject Alternative Names (SANs) covered by each certificate. If you want to see all certificates including wildcards and subdomains, search for %.example.com instead—the % acts as a wildcard in the query. The results are sorted by timestamp, making it easy to spot recent activity and identify patterns like bulk certificate issuance or unexpected entries.

While crt.sh is fast and free, it doesn't notify you of new certificates automatically. You'd have to check it manually every day to spot unauthorized issuance—impractical for busy teams. That's where automated monitoring comes in.

Google Certificate Transparency Search

Google operates its own Certificate Transparency Search tool (https://transparencyreport.google.com/https/certificates), which provides a cleaner, more visual interface for searching and tracking certificates. Google's tool presents a timeline view, making it easier to identify when certificates were issued and notice unusual patterns. The interface also clearly shows certificate details including validity dates, certificate SHA-1 fingerprint, and all domain names covered. For organizations that prefer Google's tools or want integration with other Google services, this is a solid alternative to crt.sh. The information is essentially the same—both query the same CT logs—but the presentation is different, and some people find one interface more intuitive than the other.

Setting Up Automated CT Monitoring

Manual checking is unreliable; automated monitoring is the professional approach. Several services offer this capability: Censys (https://censys.io) provides certificate monitoring with email alerts when new certificates are detected for your domain. Entrust Certificate Search (https://www.entrust.com/ct-search) offers similar functionality. Alternatively, if you're technically inclined, you can write a script that queries CT log APIs daily and sends alerts when new certificates appear. Some commercial security platforms like Qualys SSL Labs and ZeroSSL include CT monitoring built in. The key feature to look for: alerts should reach your security team's email or Slack immediately when new certificates are found, not buried in a dashboard you check occasionally.

AsiaGB offers SSL certificates starting at 1,000 THB/year for basic DV certificates, or 5,000 THB/year for Wildcard SSL if you need to cover multiple subdomains. When you purchase SSL from AsiaGB, our support team (email: [email protected] or ticket at billing.in.th/submitticket.php) can help guide you through setting up CT monitoring and responding quickly if suspicious activity is detected.

The Subdomain Exposure Tradeoff

Certificate Transparency provides enormous security value, but there's a privacy cost: every certificate must list all domain names it covers, including subdomains. This information is public and searchable. Attackers use CT logs for reconnaissance—they search your domain, see all your subdomains (internal APIs, development systems, test databases, etc.), and then probe those systems for vulnerabilities.

Some organizations try to hide sensitive internal systems by using self-signed certificates or avoiding HTTPS on internal subdomains—but that creates different security problems. The best balance is to: (1) Only include subdomains in your SSL certificate if they genuinely need HTTPS, (2) Use separate certificates for truly sensitive infrastructure instead of bundling everything into a wildcard, and (3) Keep internal systems behind VPNs or firewalls rather than relying on certificate obscurity for security.

Best Practices for Effective CT Monitoring

Here are professional practices for maintaining effective Certificate Transparency monitoring:

• Enable alerts immediately—Use a service that sends notifications to your security team the moment a new certificate is detected. Email is the minimum; Slack or your incident response platform is better.
• Maintain a certificate inventory—Keep a documented list of all certificates you've authorized for your domains. This makes it trivial to spot unauthorized entries in CT logs.
• Check at least weekly—Even if you have alerts, check CT logs manually on a regular schedule. Alerts can fail or get filtered; a deliberate audit catches things alerts might miss.
• Have a revocation process—Know exactly who to contact at your CA to revoke a certificate and how fast they can do it. Most CAs offer revocation within minutes, but some require extra steps.
• Monitor multiple logs—Chrome requires certificates to have SCTs from at least two different CT logs. Familiarize yourself with major logs like Google Argon, Google Skylight, Sectigo Sabre, and DigiCert Yeti.
• Rotate certificates regularly—Even authorized certificates should be replaced every 90 days (or as often as your policy requires). This limits the window an old compromised key can be misused.

Understanding the CT Log Ecosystem

Multiple independent CT logs exist to prevent any single log operator from becoming a single point of failure. Major logs include Google Argon (the most common destination for new certificates), Google Skylight (for legacy certificates), Sectigo Sabre, and DigiCert Yeti. Each log is operated independently and maintains its own append-only ledger. Browsers verify certificates against these logs to ensure they're legitimate. When you search crt.sh or Google's tool, you're querying aggregators that pull data from multiple CT logs and present them in a unified interface.

Understanding this ecosystem matters because: (1) It takes time for a certificate to propagate across all logs (usually within 24 hours), (2) Different logs might have slightly different retention policies, and (3) For maximum coverage, you should monitor the major logs, not just one.

Responding to Unauthorized Certificates

If you find a certificate in CT logs that you didn't authorize:

1. Identify the certificate: Note the CA that issued it, the exact domain names it covers, the serial number, and when it was issued.
2. Contact the CA immediately: Email or call your CA's security team and request revocation. Provide the serial number. Most CAs respond within minutes.
3. Monitor the revocation: Check the CA's revocation status or OCSP endpoint to confirm the certificate is actually marked as revoked. Don't assume it's revoked until you verify.
4. Enable HSTS preload (if applicable): If the certificate covered your main domain, consider enabling HSTS preload to prevent browsers from ever accepting the certificate, even if the revocation check fails.
5. Investigate root cause: Did your CA account get compromised? Did someone in your organization request the certificate without telling you? Did DNS get hijacked? Understanding how the unauthorized cert appeared helps you prevent recurrence.
6. Document the incident: Log the details, timeline, and resolution in your security records for compliance and post-incident review.

Common Questions About Certificate Transparency Monitoring

Is Certificate Transparency monitoring a legal requirement?

No, it's not legally mandatory, but it's a best practice. If your organization handles sensitive data or operates in regulated industries (finance, healthcare, etc.), your compliance requirements might mandate certificate monitoring as part of your security controls. Either way, it's worth doing voluntarily as part of a solid security program.

How often should I check Certificate Transparency logs?

Ideally, continuously via automated monitoring. If that's not feasible, check at least weekly. Large organizations often check daily as part of their security routine. The key is to catch unauthorized certificates within hours or days, not weeks.

Do Wildcard certificates expose my entire infrastructure?

Not completely. A Wildcard certificate for *.example.com covers any first-level subdomain (a.example.com, b.example.com) but not multi-level subdomains (a.b.example.com). However, the mere fact that you're using a Wildcard certificate is visible in CT logs, signaling to attackers that you have multiple subdomains.

What's the best way to respond if a competitor or troll issues a certificate for my domain as a prank?

Treat it seriously. Even prank certificates can be misused. Contact the CA, request revocation, and report the incident. If it happens repeatedly from the same person or IP address, file a police report or contact a lawyer. Don't ignore it hoping it goes away.

Can I hide my subdomains from Certificate Transparency logs?

Not if those subdomains need HTTPS. The moment you issue an SSL certificate covering a subdomain, its name appears in CT logs. Your only options are to use internal-only certificates (not browser-trusted), use a VPN for internal traffic, or accept that the subdomains are discoverable.

Which CT monitoring service is best for small businesses?

For teams that can't afford premium services: Start with free crt.sh or Google Certificate Transparency Search and check manually monthly. Set a calendar reminder. As you grow, graduate to a free tier on Censys or implement a simple CT log monitoring script. Most small teams find that manual monthly checks paired with security monitoring on their main domain is sufficient if nothing has changed.