Every time you click the padlock in your browser, you are trusting that the website is who it claims to be. For a long time, that trust had a serious gap, and that gap was certificate misissuance. Certificate Transparency (CT) was built to fix that problem, and today it sits at the heart of how Chrome, Safari, and other modern browsers decide whether to trust an SSL/TLS certificate.
This article explains what Certificate Transparency is, why it was created, how it works, and what your organization needs to know to stay compliant and protected.
What Is Certificate Transparency (CT)?
Certificate Transparency is an open framework, originally proposed by Google in 2013 and standardized in RFC 6962. It makes the issuance of SSL/TLS certificates publicly auditable. Put simply, CT answers one key question, how do you know a Certificate Authority (CA) issued a certificate for your domain legitimately and not by mistake or through compromise?
Before CT existed, a CA could issue a certificate for any domain without the domain owner ever knowing. An attacker who managed to fool or compromise a CA could receive a valid certificate for google.com or yourbank.com, and browsers would trust it without question. The DigiNotar breach of 2011 made this threat very real, when attackers obtained fraudulent certificates for major domains including Google.
Certificate Transparency solves this by requiring that every publicly trusted certificate be recorded in a public, append-only log before browsers will trust it. This turns certificate issuance from a private act into a publicly verifiable one.
Why Was Certificate Transparency Introduced?
The Public Key Infrastructure (PKI) model works on a chain of trust. Browsers trust a set of root Certificate Authorities. Those CAs issue certificates to websites, and browsers accept them. In theory, this works well, but in practice, it created a weak link, the CAs themselves.
The DigiNotar incident was not a one-off. Certificate misissuance, through negligence, human error, or compromise, happened at multiple CAs over the years. The real problem was not just that bad certificates were issued. The problem was that nobody outside the CA knew about them. Domain owners had no visibility, security researchers had no way to audit, and browsers had no way to catch the fraud in time.
Certificate Transparency closed that accountability gap. By requiring all certificates to be logged publicly, any misissued certificate becomes visible to domain owners, security researchers, and browsers quickly, before it can cause real harm.
How Certificate Transparency Logs Works
The engine behind Certificate Transparency is the CT log, a publicly accessible, append-only ledger that records every certificate submitted to it. Think of it as a public notary for internet certificates. Here is how the process works:
- Certificate Issuance: A CA issues an SSL/TLS certificate for a domain. The certificate or a pre-certificate is submitted to one or more CT logs before or shortly after issuance.
- Log Entry and SCT: The log server accepts the submission and returns a Signed Certificate Timestamp (SCT), which is a cryptographically signed receipt proving the certificate was logged at a specific time.
- Merkle Tree Structure: CT logs use a Merkle hash tree to record certificates in a tamper-evident structure. Every entry is cryptographically chained to the ones before it, so any attempt to alter or delete a historical entry is immediately detectable
- Append-Only Enforcement: Logs are strictly append-only. Certificates can be added but never removed. This means there is no way for a CA to quietly erase evidence of a misissued certificate.
- Public Accessibility: CT logs are open to everyone. Researchers, domain owners, and security tools can query them to see every certificate logged for any domain.
Multiple CT logs exist today, operated by Google, Cloudflare, DigiCert, and others. Browsers maintain a list of trusted logs, and only SCTs from these approved logs count toward CT compliance.
Understanding Signed Certificate Timestamps (SCTs)
A Signed Certificate Timestamp (SCT) is the cryptographic proof that a certificate has been submitted to a CT log. It is what the browser checks to confirm the certificate was publicly logged before it agrees to trust the connection.
An SCT holds three things: the Log ID identifying which CT log issued it, a timestamp showing when the certificate was logged, and a digital signature from the log confirming the entry is genuine. SCTs can be delivered to browsers in three ways: embedded directly in the certificate itself, included in the TLS handshake via a TLS extension, or provided through OCSP stapling. Most modern CAs embed SCTs directly at the time of issuance, so the process is invisible to server operators.
Browsers typically require two or more SCTs from distinct, approved logs. This redundancy means that even if one log goes offline or becomes distrusted, CT compliance can still be verified from the remaining SCTs.
Why Chrome and Safari Require Certificate Transparency
Google Chrome began requiring CT compliance for all publicly trusted certificates in April 2018. Apple’s Safari followed shortly after with its own CT policy, covering all certificates issued after October 15, 2018. These were not arbitrary decisions. They came after years of documented CA failures and a recognition that voluntary CT adoption was too slow.
If a certificate does not include valid SCTs from browser-trusted logs, Chrome and Safari will show a certificate error. The site will appear untrusted, warnings will appear for users, and in enterprise environments, automated systems may block the connection entirely.
A certificate without valid SCTs is treated the same as an expired or self-signed certificate by Chrome and Safari. For businesses, that means broken workflows, lost revenue, and damaged customer trust.
The CT requirements from Chrome and Safari also pushed the entire CA ecosystem to comply. Any CA that wants to remain trusted by these browsers must submit certificates to CT logs, making CT participation a non-negotiable requirement for operating in the PKI space. Note that CT requirements apply only to publicly trusted certificates. Internal certificates issued by private CAs for intranet use are exempt from browser CT requirements, though monitoring internal PKI with CT-style logging is increasingly recommended as a security best practice.
How Encryption Consulting Can Help
Certificate Transparency gives your organization visibility into what certificates have been issued for your domains. But that visibility only becomes useful if someone is actually watching. Most security teams do not have the time or tooling to actively monitor CT logs alongside everything else they are managing. That is the gap CertSecure Manager is built to close.
CertSecure Manager is Encryption Consulting’s Certificate Lifecycle Management platform. Beyond managing your own certificate inventory, it gives your team the discovery and monitoring capabilities that make CT genuinely useful rather than just a compliance checkbox.
Here is where it directly supports:
- Certificate Discovery Across Your Environment: CertSecure Manager scans your infrastructure to build a complete, up-to-date inventory of every SSL/TLS certificate tied to your domains, including certificates you may not know were issued. If an unauthorized certificate appears, you want to know about it before an attacker uses it.
- Expiry and Renewal Automation: CT compliance requires valid SCTs from browser-trusted logs. That requirement resets every time a certificate is renewed. CertSecure Manager automates the renewal process, so your certificates are always current, always CT-compliant, and never left to expire quietly.
- Audit Trail and Compliance Reporting: Every certificate event, issuance, renewal, and revocation, is logged in CertSecure Manager, giving you the documentation your security and compliance teams need when questions arise.
- Centralized Visibility: Managing certificates across multiple domains, environments, and teams without a centralized platform means relying on spreadsheets and calendar reminders. CertSecure Manager replaces that with a single, structured view of your entire certificate environment.
CT logs are public. That means the certificates issued for your domains are visible to everyone, including attackers looking for opportunities. Having the right tools to monitor and manage your certificate landscape is not optional anymore.
Conclusion
Certificate Transparency is one of the rare security technologies that actually delivered on what it promised. It turned certificate issuance from an opaque process into something publicly verifiable and tamper evident. With Chrome and Safari enforcing CT requirements, compliance is simply a baseline for any organization operating on the public internet.
But compliance alone is not enough. Organizations that treat CT as just a checkbox miss its most useful feature, which is the ability to monitor logs for unauthorized certificates and act before damage occurs. In an environment where attackers are sophisticated and supply chain compromises are common, that early warning capability matters.
