CT (Certificate Timestamp)

created on

August 26, 2026

Certificate Transparency addresses the fact that, ultimately, a CA cannot be trusted, and seeks to mitigate this by moving the signing of certificates into the public view.

Certificate Transparency started in 2012 as an open-source project of the two Google engineers Ben Laurie and Adam Langley. Laurie and Langley created a working draft outlining Certificate Transparency in collaboration with the IETF and published RFC 6962 in June 2013, Certificate Transparency (experimental). The same year, Google launched two public logs and announced plans to eventually making CT mandatory for all EV SSL Certificates in Google Chrome.

In 2021, the CT specification got updated by RFC 9162, Certificate Transparency Version 2.0, which obsoleted RFC 6962.

Certificate transparency aims to mitigate the problem of incorrectly issued and/or compromised certificates by providing publicly auditable, append-only logs of all issued certificates. The logs are publicly auditable by anyone, so anyone can verify the correctness of a log.

PKI with Signed Certificate Transparency, with Certificate Embedding

click on image to enlarge

CT logs

CT logs use a binary Merkle Hash Tree with the SHA-256 hashing algorithm for efficient auditing.

Inclusion of a CT log requires into the publicly trusted CT logs club requires a high degree of availability, evidenced through a 90-day testing period. Any log failing the 90-day testing period, showing considerable downtime or is exhibiting other noticeable erroneous behaviour is untrusted.

the need for multiple logs and multiple SCTs

The set of logs trusted by TLS clients is neither unified nor static. Clients maintain an independent list of trusted logs. Over time, currently trusted logs may become untrusted, and new logs become trusted – note that trust and distrust of logs are handled out of band.

If a malicious or compromised CA and a log collude, it is temporarily possible to hide the fact from clients that certificates have been issued incorrectly. If a TLS client checks SCTs from multiple logs, it is unlikely that attacks from a compromised CA, colluding with a log, succeed.

If a CT log operator’s private key gets compromised, clients will cease to trust it. Providing SCTs from multiple logs reduces the probability of a certificate being rejected by TLS clients.

Vendors of clients establish CT Policies, which specify the requirements for certificates which are used in TLS-secured communications, and the CT logs in which those certificates are listed. I.e., the CT Policy for Google Chrome requires several SCTs for a certificate for the cert to be accepted by Chrome, and it also specifies the operational requirements and the service levels for CT logs to be trusted by Google Chrome. Google’s CT Policy for Chrome also contains a detailed description of the application process for new CT logs, which a new CT log has to pass in order to become trusted.

CT Monitors

Monitors watch logs, check that they behave correctly, and watch for certificates of interest. To achieve this a monitor needs to inspect every new entry in each log it watches. Additionally, it may also want to keep copies of entire logs.

status of CT support for logs, browsers and CAs

Chrome started supporting CT in early 2014.

SCT delivery methods

Certificate Embedding

Before issuance, the CA submits a pre-certificate to the log, and the log returns the SCT. The CAs attaches the SCT to the certificate by embedding the SCT proofs in the certificate’s Transparency Information X.509v3 Extension before it is signed. This method is more convenient for server operators, as it does not require any server modification or any other action on the part of the server operator.

TLS Extension

The CA issues the certificate and hands it over to the server operator, who submits the certificate to the CT log. The log sends the SCT to the server operator. The server operator configures the server to use the TLS extension to deliver the SCT during the handshake. This method reduces certificate size and does not require any action on the part of the CA, but it less convenient for server operators.

OCSP Stapling

The CA issues the certificate to both the log server and the server operator. This method allows the CA to deliver the certificate before receiving the SCT. The CA returns the SCT received y the CT log to the server operator as part of the server’s request for the OCSP response. The response, which includes the SCT as an OCSP extension, is then provided to clients by the server during the TLS handshake. Of course, this method requires the server operator to enable OCSP stapling on the server.

OCSP Stapling for SCT delivery is dead in the water.

status of SCT delivery methods

Theodor Nolte conducted research during his master thesis Certificate Transparency Deployment Study, Nov. 2018, evaluating the adoption of CT by the Alexa. Top 1M sites between September 2017 and October 2018.

While in Sept. 2017, 25.54% of certificates were deployed with SCT, in Okt. 2018 the percentage of certs deployed with SCT had more than doubled to 57.51%, with most certificates providing 2 SCTs (43.10 of the 57.51% with CT) and 3 SCTs (10.88 of the 57.51% with CT). The amount of certificates providing 4 or 5 SCTs was negligible.

During that period, the total number of certificates deployed with Certificate Embedding roughly doubled from ca. 865k to ca. 1,791k, and amounted for 83.40% of all certs deployed with CT in Sept. 2017, rising to 93.96% of all certificates deployed with CT in Okt. 2018.

During the same period, the percentage of certs deployed with TLS Extension dropped from 16.58% to 6.01%, while deployment of certificates using OCSP Stapling for SCT delivery was at a negligible 0.03% both in Sept. 2017 and Okt. 2018.

The high adoption of Certificate Embedding likely stems from the fact that for domain owners, this method is the most convenient SCT delivery method, as mentioned above. Given its deservedly poor reputation in the past, it is no wonder that OCSP Stapling as a SCT delivery method is dead in the water. One really has to wonder why OCSP Stapling was even considered as a way to provide SCTs.

Aside: a staggering ca. 20% of all Alexa. Top 1M sites offered no certificate during TLS handshake tries in both in Sept. 2017 and Okt. 2018.

security considerations

CT is presented as a big improvement, but comes with a new set of problems.

Public CT logs permanently record every issued certificate, including internal or hidden subdomains. Attackers can easily mine these logs to map out an organization’s complete network infrastructure. Both security researchers and malicious actors use tools to monitor real-time log issuance for target reconnaissance, discovering unmaintained assets or shadow IT assets the moment a certificate is generated.

CT fosters centralization and reliance on Google: The system heavily relies on major tech entities —particularly Google— to manage, enforce, and dictate log policies, creating a dynamic where clients must blindly trust that the logs themselves are correct.

Original proposals included “gossip protocols” so browsers could verify that log servers are not serving split views or lying to different clients, but full adoption of these safeguards remains limited.