SCT デコーダー：Certificate Transparency

Certificate Transparency and SCTs

Certificate Transparency makes every publicly trusted TLS certificate a matter of public record. Before a CA issues a certificate, it submits it — as a precertificate carrying a "poison" extension that makes it unusable — to append-only logs run by independent operators. Each log answers with a Signed Certificate Timestamp: a promise, signed with the log's key, to include the certificate within its maximum merge delay. The format is defined in RFC 6962 §3.2: a version, the log's ID (the SHA-256 of its public key), a timestamp in milliseconds, optional extensions and a TLS-style digitally-signed structure.

SCTs reach the browser in one of three ways, and the decoder reads all of them: embedded in the certificate itself in an X.509 extension (the common case), in the signed_certificate_timestamp TLS extension during the handshake, or in a stapled OCSP response (RFC 6962 §3.3). Chrome and Safari refuse certificates without enough valid SCTs; that is why a CA's CT outage stops issuance.

What the decoder checks

Paste a certificate — best together with its issuer, or the whole chain as a server sends it — or the hex or base64 of a TLS extension or OCSP response. For every SCT the decoder:

• names the log. The log ID is looked up in the log lists the browsers themselves publish: Chrome's all_logs_list.json and Apple's current_log_list.json, built into the page. You see the log's name, its operator, its state in each program — pending, qualified, usable, read-only, retired or rejected — and, for temporally sharded logs, the range of expiry dates it accepts. An SCT from a rejected log, or from a shard that does not cover the certificate's expiry, does not count.
• verifies the signature. An embedded SCT signs the precertificate, not the certificate you hold, so the decoder rebuilds it: it removes the SCT list extension from the to-be-signed certificate and combines it with the SHA-256 hash of the issuer's public key — which is why the issuer is needed. SCTs from TLS or OCSP sign the final certificate instead. ECDSA and RSA signatures with SHA-256 and SHA-384 are checked with the log's key from the list.
• checks the policy. Browsers require SCTs from at least two different log operators, and Chrome asks for three when a certificate is valid for more than 180 days. The summary says whether the certificate meets that, and the findings explain why not.

Timestamps in the future, SCTs logged long after the certificate's notBefore and SCT extensions (static-ct-api logs put a leaf index there) are reported too.

Private and test logs

Logs that are not in the browser lists — a private CT log in a company PKI, or the test log of the RFC 6962 reference implementation — can be added by pasting their public key. Their SCTs are then named and verified like any other. The third example uses the test log key and the test-cert.proof vector of Google's certificate-transparency repository to show an SCT delivered in a TLS handshake.

What runs where

The decoding, the log lookup and every signature check run in your browser. The log lists are a snapshot built into the page; the decoder does not contact any CT log, and nothing you paste is sent anywhere. Share links carry the certificate and options in the URL fragment, which browsers do not send to servers, and never a private key. For the full story of how logs, monitors and auditors fit together, see Certificate Transparency for developers; to see the whole certificate, open the certificate decoder.