Let's Encrypt
ISRG celebrates 10 years of helping build a brighter Internet →

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.

Funding

We'd like to thank the following partners for generously sponsoring the Let's Encrypt CT log. If your organization would like to help us continue this work, please consider sponsoring or donating.

Sectigo

Architecture

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 progress through can be found here.

Production

Testing


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
done

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" \
   https://oak.ct.letsencrypt.org/2020/ct/v1/add-chain
{"sct_version":0,"id":"5xLysDd+GmL7jskMYYTx6ns3y1YdESZb8+DzS/JBVG4=","timestamp":1576689972016,"extensions":"","signature":"BAMARzBFAiEA4OmuTcft9Jq3XLtcdZz9XinXCvYEY1RdSQICXayMJ+0CIHuujkKBLmQz5Cl/VG6C354cP9gxW0dfgMWB+A2yHi+E"}

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:]'
E7:12:F2:B0:37:7E:1A:62:FB:8E:C9:0C:61:84:F1:EA:7B:37:CB:56:1D:11:26:5B:F3:E0:F3:4B:F2:41:54:6E

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:]'
04:03:00:47:30:45:02:21:00:E0:E9:AE:4D:C7:ED:F4
9A:B7:5C:BB:5C:75:9C:FD:5E:29:D7:0A:F6:04:63:54
5D:49:02:02:5D:AC:8C:27:ED:02:20:7B:AE:8E:42:81
2E:64:33:E4:29:7F:54:6E:82:DF:9E:1C:3F:D8:31:5B
47:5F:80:C5:81:F8:0D:B2:1E:2F:84