Summary

  • A Signed Certificate Timestamp is a log’s promise to incorporate a certificate entry; browser acceptance also depends on the client’s policy, effective log list, operator diversity, SCT delivery and certificate lifetime.
  • Release public certificates against evidence from the intended browser population, not against the certificate pipeline’s count of SCTs.

The certificate pipeline reports success. The new certificate contains three Signed Certificate Timestamps, each signature verifies, and the deployment job has copied the certificate to the edge. A browser population still refuses the handshake.

That is not a contradiction. It is the difference between a receipt and a relying-party decision.

RFC 9162 gives an SCT a narrow, important meaning. A Certificate Transparency log that accepts a valid submission returns a signed promise to incorporate that entry into its append-only Merkle tree within the Maximum Merge Delay. The promise can later be audited through tree heads and inclusion proofs. The same standard states that SCT validation is not a substitute for ordinary validation of the server certificate and its chain.

Browser policy adds another layer. Chrome says CT compliance depends on how SCTs are delivered, how many distinct logs contributed them, whether those logs represent distinct operators, and the state of a log both when the SCT was created and when the certificate is checked. For an embedded SCT set on a certificate lasting no more than 180 days, Chrome currently requires at least two qualifying distinct logs and two distinct operators, with at least one SCT from a log in a contributing state at check time. The route for SCTs delivered through TLS has its own criteria.

Three receipts are therefore not automatically better than two. If they come from logs that do not count, from one recognised operator, or through a delivery path that does not meet the applicable rule, the arithmetic is misleading.

The log set is part of the decision

Chrome publishes a fresh CT log list every day. The list identifies logs and operators that Chrome uses when evaluating its own policy. Chrome also records lifecycle states such as Qualified, Usable, ReadOnly, Retired and Rejected. The policy asks questions about state at two times: issuance and validation. A static inventory of “trusted logs” is not enough to reproduce that decision.

There is a second clock. Chrome enforces CT only while its freshest supported stored log list is within 70 days. If an installed client has missed both software and component updates long enough, CT enforcement is disabled. An external probe that happens to succeed on such a client is not positive proof of current CT compliance. The probe must preserve the client version, effective log-list timestamp and whether enforcement was active.

The log list is also not a neutral standards registry. Chrome signs and publishes it for certificate submitters, monitors and auditors that need compatibility with the Chrome ecosystem. Chrome explicitly warns other user agents against repurposing that list as their own enforcement authority. A platform can use it to model Chrome, but it cannot treat it as a universal browser policy.

Apple demonstrates why. Apple requires publicly trusted TLS server certificates to satisfy its own CT policy. Its published rules distinguish currently approved and once-approved logs, impose their own SCT combinations and limit how many SCTs from one operator count. Both companies use the same broad CT mechanism. They do not reduce relying-party acceptance to one universal receipt test.

Temporal shards turn log choice into time-bounded state

Chrome’s log policy requires new logs to be temporally sharded. Each shard declares a certificate-expiry interval and rejects submissions whose notAfter falls outside it. Operators are expected to provide contiguous expiry coverage, usually through a family of logs.

For an issuer, that makes log eligibility a function of the certificate’s expiry date as well as operator and lifecycle state. For a subscriber, it makes the evidence time-bounded: the log IDs and SCT timestamps attached to this certificate must be evaluated against the policy and log metadata that apply to this certificate, not merely against a current list of familiar log names.

Chrome’s own guidance to site operators adds the practical warning. CT information in an existing certificate can lose validity before the certificate itself expires. In that case, the operator may need fresh SCTs through the TLS handshake or a replacement certificate. A certificate-expiry monitor will not see this earlier acceptance risk.

Draw the evidence boundary honestly

The verified facts here are public policy and protocol statements: what an SCT promises; what Chrome and Apple say their clients require; how Chrome publishes and changes its log set; and how temporal shards are scoped.

The operational conclusion is an inference: an organisation serving a mixed client estate should reconcile issuer receipts with client-specific acceptance evidence. Public sources do not reveal any subscriber’s browser distribution, TLS termination map, exception policies, simulator accuracy, outage record or contractual allocation. They do not establish that a named certificate authority or log is presently failing. Those facts remain unknown until the operator measures and preserves them.

The right release object is a relying-party acceptance ledger. For every certificate, record the fingerprint, names and termination points, SCT delivery path, log IDs and timestamps, effective Chrome and Apple policy/log-set evidence, tested client and version, external handshake result, exceptions, accountable owner and remaining recovery time. Preserve failed probes as evidence rather than averaging them into a green percentage.

Certificate Transparency was designed to make issuance observable. Operations fail when observability is mistaken for acceptance. The certificate pipeline owns the receipt; the service owner still owns the proof that intended clients can connect.

Sources