Certificate Transparency (CT) Logs

Se på Dansk

Auf Deutsch ansehen

Ver en español

Voir en Français

לעבור לעברית

Megtekintés magyar nyelven


한국어로 보기

Просмотреть на русском

Переглянути українською



Last updated: | See all Documentation

Certificate Transparency (CT) is a system for logging and monitoring the issuance of TLS certificates. CT greatly enhances everyone's ability to monitor and study certificate issuance, and these capabilities have led to numerous improvements to the CA ecosystem and Web security. As a result, CT is rapidly becoming critical infrastructure.

Let's Encrypt submits all certificates we issue to CT logs. We also operate two annually sharded CT logs named Oak and Sapling. All publicly trusted certificate authorities are welcome to submit to our logs. Many certificate authority root certificates have already been included in our CT logs. If you operate a Certificate Authority and your issuer is not in our accepted issuers list, please file an issue here.

Sign up for notifications in the CT announcements category of our community forum to see major announcements about our CT logs.


If your organization would like to help us continue this work, please consider sponsoring or donating.


Check out our blog to see How Let's Encrypt Runs CT Logs!

Log Monitoring

Let's Encrypt has created an open-source CT log monitoring tool called CT Woodpecker. We use this tool to monitor the stability and compliance of our own logs, and we hope others will find it to be useful as well.

CT Logs

Information about the various lifecycle states that a CT log progresses through can be found here.




Log Operations

To enumerate the included roots for a particular CT log, you can run the following command in the terminal of your choice:

$ for i in $(curl -s https://oak.ct.letsencrypt.org/2020/ct/v1/get-roots | jq -r '.certificates[]'); do
    echo '------'; base64 -d <<< "${i}" | openssl x509 -inform der -noout -issuer -serial

Submitting certificates to a CT log is typically handled by certificate authorities. If you'd like to experiment with this, begin by retrieving an arbitrary PEM encoded certificate from our favorite website. Copy and paste the following block into your terminal.

$ echo | \
openssl s_client \
    -connect "letsencrypt.org":443 \
    -servername "letsencrypt.org" \
    -verify_hostname "letsencrypt.org" 2>/dev/null | \
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > example.crt

Before a certificate can be submitted, it must be JSON encoded within a special structure. You can use the JSON generator provided by https://crt.sh/gen-add-chain to perform this task. The crt.sh utility will return a JSON bundle. Download the bundle to your computer, rename the file if you must, and issue the following command to perform the add-chain operation (RFC 6962 section 4.1) to submit the certificate to a CT log. The output will contain a signature which is in fact an SCT. More on the signature in a moment.

$ curl \
    -X POST \
   --data @example-json-bundle.json \
    -H "Content-Type: application/json" \
    -H "User-Agent: lets-encrypt-ct-log-example-1.0" \

To confirm that the CT log was signed by the Oak 2020 shard, we use the id field from the command above and run it through the following command. The result of this will output the Log ID of the CT log.

$ base64 -d <<< "5xLysDd+GmL7jskMYYTx6ns3y1YdESZb8+DzS/JBVG4=" | xxd -p -c 64 | sed -e 's/../&:/g' -e 's/:$//' | tr '[:lower:]' '[:upper:]'

Using the signature field, we can verify that the certificate was submitted to a log. Using our SCT deep dive guide, you could further decode this value.

$ base64 -d <<< "BAMARzBFAiEA4OmuTcft9Jq3XLtcdZz9XinXCvYEY1RdSQICXayMJ+0CIHuujkKBLmQz5Cl/VG6C354cP9gxW0dfgMWB+A2yHi+E" | xxd -p -c 16 | sed -e 's/../&:/g' -e 's/:$//' | tr '[:lower:]' '[:upper:]'