SSL guide
Certificate Transparency Explained: Logs, SCTs and Monitoring
Certificate Transparency puts every publicly trusted SSL/TLS certificate into public logs. Here is how the logs work, what an SCT proves and how to monitor certificates for your domain.
Certificate Transparency (CT) is a public logging system for SSL/TLS certificates. Certificate authorities (CAs) must record every publicly trusted certificate in append-only logs that anyone can search. Browsers check for proof of logging before they trust a certificate, and domain owners use the logs to spot certificates they never requested.
This guide covers how the logs work, what a Signed Certificate Timestamp (SCT) is, how to set up SSL certificate transparency monitoring, and what CT reveals about your subdomains.
| Key fact | What it means |
|---|---|
| Standard | Defined by the IETF in RFC 6962 (2013) |
| Who submits | The issuing CA, before or at issuance |
| Proof of logging | An SCT – a signed receipt from the log |
| Enforced by | Chrome (certificates issued after 30 April 2018), Apple platforms (issued after 15 October 2018), Firefox on desktop (since version 135, February 2025) |
| Who can read the logs | Anyone – the logs are public |
CT shows what was issued. Management keeps it under control.
Track owners, expiry dates and renewals for every certificate your logs reveal.
Read the certificate management guideHow certificate transparency logs work
A CT log is a public, append-only record of certificates. Append-only means entries can be added but never changed or deleted. Each log is built as a Merkle tree, a data structure that lets anyone prove a certificate is in the log and that the log has not been rewritten.
Several independent organizations operate logs, including browser vendors and CAs. Browsers keep a list of logs they accept. Firefox, for example, takes its list of trusted logs from Google’s list.
CT does not stop a CA from issuing a bad certificate. It makes every issuance visible, so mistakes and abuse are found quickly instead of staying hidden.
How a certificate gets logged
CA prepares the certificate
After validation, the CA creates a precertificate – a version of the certificate that cannot be used on a server yet.
Logs return SCTs
The CA submits the precertificate to several CT logs. Each log answers with a signed timestamp (SCT).
CA issues the final certificate
The CA embeds the SCTs in the certificate and delivers it to you. You install it as usual.
Browser checks the proof
During the TLS handshake, the browser verifies the SCTs. Without enough valid SCTs, the connection fails with a CT error.
What is an SCT?
An SCT (Signed Certificate Timestamp) is a log’s signed promise that it has recorded a certificate. It is the proof of logging that browsers look for. The log commits to publishing the entry within a set window, called the maximum merge delay.
RFC 6962 defines three ways to deliver SCTs to a browser. You rarely need to choose: with certificates bought today, the CA embeds them for you.
| Delivery method | Where the SCT lives | What you need to do |
|---|---|---|
| Embedded in the certificate | An X.509 extension inside the certificate | Nothing – the CA handles it |
| TLS extension | Sent by your server during the handshake | Server configuration |
| OCSP stapling | Inside the stapled OCSP response | Stapling enabled and supported by the CA |
If a browser shows a CT error such as Firefox’s MOZILLA_PKIX_ERROR_INSUFFICIENT_CERTIFICATE_TRANSPARENCY, the certificate usually comes from a private or non-compliant CA. Run the domain through the SSL checker to see the issuer and chain.
Ways to watch the CT logs
Manual log search
Public search tools such as crt.sh list every logged certificate for a domain. Good for a one-off audit.
Automated CT monitoring
A monitor checks new log entries continuously and alerts you when a certificate for your domain appears.
Monitoring inside management
Feed CT alerts into your certificate inventory so new certificates get an owner and a renewal date.
How to monitor certificates for your domain
Use a CT monitor: a service that reads the public logs and alerts you when a new certificate lists one of your domains. You then confirm each certificate was requested by your team, your host or your CDN.
- List every domain and subdomain you own, including parked domains.
- Run a manual log search to build a baseline of certificates that exist today.
- Set up automated alerts for new entries, routed to a shared mailbox or ticket queue.
- For each alert, check the issuer and requester. Hosting platforms and CDNs often issue certificates for you automatically.
- If a certificate is unauthorized, contact the issuing CA and ask it to revoke the certificate.
Expect more log entries over time. Under CA/Browser Forum ballot SC-081, the maximum public certificate lifetime is 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. Shorter lifetimes mean more renewals, and every renewal is a new log entry. Filter expected renewals so real surprises stand out.
Tip: CT finds misissued certificates after the fact. CAA records work before issuance: they tell CAs which of them may issue for your domain. Use both.
Monitoring alerts only help if someone owns the follow-up. Inventory, renewals and alert routing belong to SSL certificate management, which covers the tooling side in detail.
Who should treat CT monitoring as a must
Any organization that is a phishing target benefits from CT alerts. A look-alike certificate in the logs is often the first sign of a phishing campaign. Banks and other regulated firms usually build this into brand protection – see SSL for financial services.
- Online banking, payments and lending
- Ecommerce brands with many look-alike domains
- Enterprises with many teams ordering certificates
- Agencies managing domains for clients
Does Certificate Transparency reveal my subdomains?
Yes. Every hostname in a publicly trusted certificate is published in the CT logs, where anyone can read it. If you order a certificate for staging-newproduct.example.com, that name becomes public the moment the certificate is logged.
You cannot opt out of logging for a publicly trusted certificate. You can limit what the logs show:
- Keep sensitive project names out of hostnames.
- Use a wildcard certificate where it fits: the log shows
*.example.com, not each subdomain. - For internal-only systems, use a private CA. Public CAs have not issued certificates for internal names since 2015, and private certificates are not logged. See self-signed and private certificates.
Note: Hiding a hostname is not access control. Protect staging and admin systems with authentication, not obscurity.
Turn CT alerts into a managed certificate inventory
Learn how to track owners, expiry dates and automated renewals across all your domains.
Read the certificate management guide