signed_certificate_timestamp
signed_certificate_timestamp asks the server for Certificate Transparency proofs. Chrome sends it, most libraries do not.
What it is
signed_certificate_timestamp (extension 18) comes from Certificate Transparency, described in RFC 6962. By sending it empty, the client asks the server to include signed certificate timestamps (SCTs) in the handshake: signed promises from public CT logs that the certificate has been recorded.
Certificate Transparency makes certificate issuance public. Anyone can watch the logs and spot a certificate that was issued for their domain without permission. RFC 6962 allows SCTs to arrive in three ways: through this extension, embedded in the certificate itself, or in a stapled OCSP response.
Most command-line tools and libraries do not enforce Certificate Transparency, so they have no reason to ask for SCTs.
The extension is empty in the ClientHello. The server answers with a list of SCTs, each signed by a CT log, which the client can check against the log operators it trusts.
Who sends it
Measured on 2026-10-25 against our own test server: sent by 4 of 12 clients. Position counts from 1 and ignores GREASE values.
Why it matters for fingerprinting
In our measurements only Chrome, curl_cffi, curl-impersonate chrome116 and Go net/http send it. curl, Python requests, httpx, Node.js fetch and Guzzle do not, and neither does the Firefox profile of curl-impersonate. That makes it one of the extensions that separates Chrome-like clients from typical libraries.
Check whether your client sends it
Open the test from your browser, or call it from your script, and look for signed_certificate_timestamp in the TLS details.
Run the TLS fingerprint test