Certificate Transparency is an open framework designed to protect against and monitor for certificate mis-issuances. With certificate transparency, newly-issued certificates are 'logged' to publicly-run, often independentCT logs — which maintain an append-only, cryptographically-assured record of issued TLS certificates.

In this way, certificate authorities (CAs) can be subject to much greater public scrutiny and oversight. Potentially malicious certificates, such as those that violate the CA/B ForumBaseline Requirements, can be detected and revoked much more quickly. Browser vendors and root store maintainers are also empowered to make more informed decisions regarding problematic CAs that they may decide to distrust.

Background

CT logs are built upon the foundation of theMerkle tree data structure. Nodes are labelled with thecryptographic hashes of their child nodes. Leaf nodes contain hashes of actual pieces of data. The label of the root node therefore depends on all other nodes in the tree.

In the context of certificate transparency, the data hashed by the leaf nodes are the certificates that have been issued by the various different CAs operating today. Certificate inclusion can be verified via anaudit proof which can be generated and verified efficiently, in logarithmic O(log n) time.

Certificate transparency initially came about in 2013 against a backdrop of CA compromises (DigiNotar breach in 2011), questionable decisions (Trustwave subordinate root incident in 2012) and technical issuance issues (weak, 512-bit certificate issuance by DigiCert Sdn Bhd of Malaysia).

Implementation

When certificates are submitted to a CT log, asigned certificate timestamp (SCT) is generated and returned. This serves as a proof that the certificate has been submitted and will be added to the log.

The specification states that compliant serversmust provide a number of these SCTs to TLS clients when they connect. This can be accomplished via a number of different mechanisms:

• X.509v3 certificate extension which embeds signed certificate timestamps directly into the leaf certificate
• A TLS extension of typesigned_certificate_timestamp sent during the handshake
• OCSP stapling (that is, thestatus_request TLS extension) and providing aSignedCertificateTimestampList with one or more SCTs

With the X.509 certificate extension, the included SCTs are decided by the issuing CA. Since June 2021, most actively used and valid publicly-trusted certificates contain transparency data embedded in this extension. This method should not require web servers to be modified.

With the latter methods, servers will need to be updated to send the required data. The advantage is that the server operator can customize the CT log sources providing the SCTs sent via the TLS extension/stapled OCSP response.

Browser Requirements

Google Chrome 107 and later requires CT log inclusion for all certificates issued with a notBefore date of after 30 April 2018. Users will be prevented from visiting sites using non-compliant TLS certificates.Chrome had previously required CT inclusion forExtended Validation (EV) and Symantec-issued certificates.

Applerequires a varying number of SCTs in order for Safari and other servers to trust server certificates.

Firefox desktop from version 135 requires CT log inclusion for all certificates issued by certificate authorities in Mozilla's Root CA Program.Firefox for Android does not currently require CT log inclusion.

Specifications

Browser implementations are based on the obsoleted specificationRFC 6962: Certificate Transparency (January 2025).The current specification isRFC 9162: Certificate Transparency Version 2.0.

See also

• Apple's Certificate Transparency log program
• Chrome's Certificate Transparency Log Policy