Day 30: Certificate Transparency

Phase 1 · June 12, 2026

Agenda (2–3 hours)

• Read (75 min): RFC 9162 §1–5 (CT 2.0 overview, log structure, SCTs)
• Study (30 min): How CT prevents undetected misissue; SCT verification
• Practice (45 min): Find SCTs in a real certificate; verify log inclusion
• Challenge (30 min): SCT analysis

Why Certificate Transparency Exists

Problem: A rogue or compromised CA can issue a valid cert for amazon.com.
The cert passes chain validation — nothing in TLS catches it.

Real example: DigiNotar (2011) issued fraudulent certs for Google.com,
used to MITM Iranian users. Not caught until users reported unusual browser behavior.

CT solution: All publicly-trusted CA certs must be logged to public, append-only
CT logs. The log returns a signed proof of inclusion. Browsers require this proof.
Any misissued cert is now publicly visible and auditable.

CT Log Structure: Merkle Trees

           [Root Hash]
          /            \
    [h(L|R)]          [h(L|R)]
    /     \           /     \
[cert1] [cert2]  [cert3]  [cert4]

Append-only: new leaves append to the right. Old hashes never change.
Inclusion proof: for cert2, provide [cert1, [root of right subtree]]. Client can recompute root.
Consistency proof: prove the log has only grown — no entries were changed or deleted.

The log operator can't remove a misissuance from the log. Auditors watch for inconsistencies.

Signed Certificate Timestamp (SCT)

When a CA submits a pre-certificate to a CT log, the log returns an SCT:

SignedCertificateTimestamp {
    sct_version:    v1 (0)
    log_id:         SHA-256 of the log's public key
    timestamp:      milliseconds since epoch
    extensions:     opaque
    signature:      ECDSA-P256 or Ed25519 signature
}

The SCT is a promise from the log: "this cert will be included within MMD (maximum merge delay, typically 24 hours)."

How SCTs Reach the Client

Three delivery mechanisms:

1. Embedded in the cert (X.509 extension 1.3.6.1.4.1.11129.2.4.2): CA embeds SCTs from 2+ logs into the cert before issuance
2. TLS extension (signed_certificate_timestamp #18): server sends SCTs during TLS handshake
3. OCSP stapling: OCSP response includes SCTs

Chrome requires 2+ SCTs from different logs (to prevent single-log collusion).
If SCTs are missing or stale, Chrome shows a certificate error.

Practice Exercise

# Show SCTs embedded in a certificate
openssl s_client -connect google.com:443 2>/dev/null | \
  openssl x509 -noout -text | grep -A10 "CT Precertificate"

# Get CT log list
curl -s https://www.gstatic.com/ct/log_list/v3/log_list.json | \
  python3 -m json.tool | grep '"description"' | head -10

# Look up a cert in a CT log (crt.sh)
# https://crt.sh/?q=amazon.com shows all CT-logged certs for a domain

Challenge Assignment

For a certificate from amazon.com:

1. Extract the embedded SCT extension bytes using openssl x509 -text
2. Identify: how many SCTs are embedded? Which logs issued them (by log ID)?
3. Look up the log IDs in the CT log list (log_list.json) to find log names
4. Find the timestamp field in each SCT — when was the cert logged?
5. Cross-check on crt.sh — find the same cert and verify the log entries match

Write a brief analysis: does this cert comply with Chrome's CT policy? How do you know?

Resources

• RFC 9162: Certificate Transparency 2.0
• Google CT log list: gstatic.com/ct/log_list/v3/log_list.json
• crt.sh: certificate search and CT log viewer
• Chrome CT policy: chromium.org/Home/chromium-security/certificate-transparency