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 CT logs. 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.
Information about the various lifecycle states that a CT log progresses through can be found here.
Let's Encrypt currently operates static-ct logs based on Sunlight.
Information including accepted roots, public keys, log IDs, and shard intervals is available at each log's landing page, linked below.
Sycamore and Willow are our production CT logs, accepting certificates from trusted CAs.
Twig is a test log, accepting certificates from trusted CAs as well as some additional test CAs, including the Let's Encrypt staging environment.
Let's Encrypt formerly ran logs based on Trillian, implementing the RFC 6962 API. For more information, see the end of life plan for our RFC 6962 Certificate Transparency logs.
The examples below use the Sycamore 2026h2 shard. Our logs are split into temporal shards, and each shard only accepts certificates whose expiration date falls within its interval, so pick the shard that matches your certificate from the log's landing page.
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://log.sycamore.ct.letsencrypt.org/2026h2/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. Our Static CT API logs accept the same submission API as RFC 6962 logs. 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://log.sycamore.ct.letsencrypt.org/2026h2/ct/v1/add-chain
{"sct_version":0,"id":"bP5QGUOoXqkWvFLRM+TcyR7xQRx9JYQg0XOAnhgY6zo=","timestamp":1783737642362,"extensions":"AAAFABSjxQU=","signature":"BAMASDBGAiEAzgwvZXjfPivGYoUr2p9yvFsi/vgA3DHUX+vL0Izm2g8CIQCvtWiPPUTYmFztu9ntrtFrg65JVuuCAZKDd+C+QD6wig=="}
To confirm that the SCT was signed by the Sycamore 2026h2 shard, we use the id field from the response above and run it through the following command. The result is the Log ID of the shard, which you can compare against the Log ID shown on the log's landing page.
$ base64 -d <<< "bP5QGUOoXqkWvFLRM+TcyR7xQRx9JYQg0XOAnhgY6zo=" | xxd -p -c 64 | sed -e 's/../&:/g' -e 's/:$//' | tr '[:lower:]' '[:upper:]' 6C:FE:50:19:43:A8:5E:A9:16:BC:52:D1:33:E4:DC:C9:1E:F1:41:1C:7D:25:84:20:D1:73:80:9E:18:18:EB:3A
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 <<< "BAMASDBGAiEAzgwvZXjfPivGYoUr2p9yvFsi/vgA3DHUX+vL0Izm2g8CIQCvtWiPPUTYmFztu9ntrtFrg65JVuuCAZKDd+C+QD6wig==" | xxd -p -c 16 | sed -e 's/../&:/g' -e 's/:$//' | tr '[:lower:]' '[:upper:]' 04:03:00:48:30:46:02:21:00:CE:0C:2F:65:78:DF:3E 2B:C6:62:85:2B:DA:9F:72:BC:5B:22:FE:F8:00:DC:31 D4:5F:EB:CB:D0:8C:E6:DA:0F:02:21:00:AF:B5:68:8F 3D:44:D8:98:5C:ED:BB:D9:ED:AE:D1:6B:83:AE:49:56 EB:82:01:92:83:77:E0:BE:40:3E:B0:8A