Certificate transparency is a ledger, not a secret

Wed, 03 Nov 2027 00:00:00 +0000

Certificate Transparency makes public TLS certificate issuance observable. It does not determine whether a domain owner authorized an issuance, replace certificate-chain validation, or guarantee that every certificate everywhere is logged. A misissued certificate can have valid transparency evidence. The benefit is a public trail that monitors and affected owners can investigate.

A promise is not an inclusion proof

An SCT, or Signed Certificate Timestamp, is a log’s signed promise to incorporate a submitted certificate or precertificate within its Maximum Merge Delay. It is not another certificate and is not itself proof that the entry already exists in the tree. Its timestamp records the log’s statement, not necessarily the exact issuance instant.

A Merkle inclusion proof connects a particular serialized leaf to a particular tree root and size. The verifier must authenticate that root through the relevant signed log statement and trusted log key. Accepting whatever root accompanies an untrusted proof establishes no useful external fact: an attacker can construct an entirely different tree.

Consistency proofs answer another question: whether a later tree extends an earlier tree without changing its existing prefix. One inclusion proof cannot establish that history. Signed checkpoints, consistency verification, and comparisons between independently observed views help expose a log that equivocates. Hashes make alterations detectable under these checks; they do not physically prevent a malicious operator from changing data.

Chrome applies its own CT policy to publicly trusted TLS certificates, considering SCT delivery, accepted log states, counts, and operator diversity. That is not equivalent to searching a public log during every page load, nor to deciding whether the owner requested the certificate. RFC 9162 specifies version 2 and obsoletes RFC 6962; publication alone does not establish which protocol a particular deployed log supports.

When it breaks

A valid SCT from an unacceptable log, an insufficient set of SCTs, or an incorrect delivery mechanism may fail the target client’s policy. Conversely, satisfying CT does not fix an expired, untrusted, or wrongly named certificate. Keep normal TLS validation, CT compliance, and issuance authorization as separate decisions.

Domain monitoring also needs interpretation. A newly observed name may belong to an authorized CDN, wildcard, or renewal. Compare issuer, names, fingerprints, and your issuance inventory before escalating; unexplained issuance needs investigation and corrective action, not an assumption that logging already blocked it.

Public logging can reveal certificate names. Do not submit private certificates or sensitive internal naming solely to try an experiment. A monitor’s incomplete coverage or stale data also cannot prove absence. Operational monitoring needs a declared scope and freshness, rather than treating an empty search result as a universal guarantee.

Check it quickly

Save this as ct_probe.go and run go run ct_probe.go with Go 1.23 or newer. This offline exercise uses RFC 6962’s SHA-256 Merkle construction with three synthetic strings, not real certificates or serialized CT leaves. It verifies only the middle leaf at index one in this fixed tree.

package main

import (
 "crypto/sha256"
 "fmt"
 "runtime"
)

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func leaf(data string) [32]byte {
 return sha256.Sum256(append([]byte{0}, []byte(data)...))
}

func branch(left, right [32]byte) [32]byte {
 var data [65]byte
 data[0] = 1
 copy(data[1:33], left[:])
 copy(data[33:], right[:])
 return sha256.Sum256(data[:])
}

// Only verifies index 1 of a three-leaf fixture; not a general CT verifier.
func middleOfThree(data string, proof [][32]byte, root [32]byte) bool {
 return len(proof) == 2 && branch(branch(proof[0], leaf(data)), proof[1]) == root
}

func main() {
 a, b, c := leaf("fixture-A"), leaf("fixture-B"), leaf("fixture-C")
 root := branch(branch(a, b), c)
 check(fmt.Sprintf("%x", root) == "111b905d16e9388f6e9079aaec820ab176d649b9daecabcdb3aca45fe4b6b646", "root differs from independent fixture vector")
 check(fmt.Sprintf("%x", leaf("")) == "6e340b9cffb37a989ca544e6bb780a2c78901d3fb33738768511a30617afa01d", "empty leaf vector differs")
 check(leaf("") != sha256.Sum256(nil), "an empty tree and an empty leaf are different")
 proof := [][32]byte{a, c}
 check(middleOfThree("fixture-B", proof, root), "correct inclusion proof must pass")
 check(!middleOfThree("fixture-X", proof, root), "altered entry must fail")
 badProof := append([][32]byte(nil), proof...)
 badProof[0][0] ^= 1
 check(!middleOfThree("fixture-B", badProof, root), "altered sibling must fail")
 check(!middleOfThree("fixture-B", [][32]byte{c, a}, root), "sibling order matters")
 check(!middleOfThree("fixture-B", proof[:1], root), "short proof must fail")
 check(!middleOfThree("fixture-B", append(proof, b), root), "extra proof element must fail")
 badRoot := root
 badRoot[0] ^= 1
 check(!middleOfThree("fixture-B", proof, badRoot), "wrong trusted root must fail")
 nextRoot := branch(branch(a, b), branch(c, leaf("fixture-D")))
 check(nextRoot != root, "appending an entry changes this fixture root")
 check(!middleOfThree("fixture-B", proof, nextRoot), "old proof must not verify against the new root")
 fmt.Println("correct proof accepted; altered entry, sibling, order, length, and root rejected")
 fmt.Println("empty tree differs from empty leaf; fourth entry changes root; old proof fails")
 fmt.Printf("three-leaf fixture root: %x\n", root)
 fmt.Println(runtime.Version())
}

A leaf hashes a 0x00 byte followed by its data; an internal node hashes a 0x01 byte followed by its two child hashes. These prefixes provide domain separation. For three leaves, the left subtree contains A and B, while C stands alone on the right. An empty tree and a single empty leaf also have different hashes.

The correct proof contains A’s hash and C’s hash. Recombining them with B reproduces the expected root, which was independently cross-checked with Python’s hashlib. Changing B, a sibling, their order, proof length, or the expected root fails. Appending D changes this fixture’s root, and the old three-leaf proof no longer verifies against it.

All assertions passed with Go 1.27.0 on macOS. The hardcoded test root represents an already trusted three-leaf checkpoint only within this exercise. No SCT signature, real log key, certificate encoding, network endpoint, generic inclusion verifier, or consistency proof is implemented. In particular, observing a changed root does not prove append-only growth. Browser policy enforcement and live misissuance monitoring remain separate, untested operations.

Sources

RFC 6962: Certificate Transparency, version-1 Merkle hashing, SCT promises, and proof distinctions, checked 2026-09-09.
RFC 9162: Certificate Transparency version 2, protocol scope, misissuance limits, and version history, checked 2026-09-09.
Chrome Certificate Transparency policy, client-specific SCT and log acceptance requirements, checked 2026-09-09.

A certificate chain is a path you should be able to print

Mon, 08 Jun 2026 00:00:00 +0000

A TLS session is only as trustworthy as the path from the leaf certificate back to a root the client trusts. That path is the certificate chain, and a deployment claim should be able to read it from the public edge rather than assume it.

The leaf is not the whole story

The certificate presented for the hostname is the leaf. It carries the exact subject and validity dates you check with check-tls-expiry.sh. But the leaf is signed by an intermediate CA, which is in turn signed by a root. A client validates every link in that chain. If the edge only presents a leaf without the intermediate, a deep-validation client may fail even though the leaf itself is fine.

Read the chain the edge actually sends

openssl s_client -showcerts prints every certificate in the chain the server sent. Against this site the answer is a leaf plus intermediates back toward a root the CA publishes:

certificate 0: CN=www.xbcatm.com
 issuer : C=US, O=Let's Encrypt, CN=YE1
 notAfter : Nov 19 08:37:12 2026 GMT

certificate 1: CN=YE1 (intermediate)
 issuer : C=US, O=ISRG, CN=Root YE

certificate 2/3: Root YE / ISRG Root … (trust anchors)

Four certificate blocks arrived. The site presents the leaf plus the intermediates that let a client build a path to a publicly trusted anchor. An operator who only looks at the leaf would miss whether the intermediate is present.

Why the intermediate matters for trust

The root itself is the thing a client walks up to. Intermediate issuers exist so that roots can be kept offline and revoked without reissuing every leaf. When you authorize issuance with a CAA record, you authorize the issuer (the intermediate/CA), not just the eventual leaf. The dns-caa-records note records how to make that authorization explicit. This note is the other half: confirm the presented chain actually runs through that issuer.

Check the chain without breaking the service

A read-only probe costs nothing on the wire:

$ echo | openssl s_client -connect www.xbcatm.com:443 -servername www.xbcatm.com -showcerts 2>/dev/null | grep 'BEGIN CERT' | wc -l
4

Expect at least a leaf and one intermediate. A chain of exactly one certificate with no intermediate for a public CA is a signal the edge is not sending the full path and should be investigated before trusting the rollout.

Sources

RFC 8446 — TLS 1.3, certificate message and presentation in the handshake, checked 2026-06-08.
RFC 5280 — X.509 PKI, certificate paths and trust anchors, checked 2026-06-08.
Let’s Encrypt: Certificate Chains, intermediate issuance and chain presentation, checked 2026-06-08.
OpenSSL s_client, -showcerts chain inspection, checked 2026-06-08.

Certificates · XB Field Notes

Certificate transparency is a ledger, not a secret

A promise is not an inclusion proof

When it breaks

Check it quickly

Further reading

Sources

A certificate chain is a path you should be able to print

The leaf is not the whole story

Read the chain the edge actually sends

Why the intermediate matters for trust

Check the chain without breaking the service

Sources