How do you pre-stage Certificate Transparency before a high-stakes cert issuance?

How do you pre-stage Certificate Transparency before a high-stakes cert issuance?

CT (Certificate Transparency, RFC 6962 and its successor RFC 9162) means every publicly-trusted certificate appears in append-only logs. For a launch where you cannot afford a surprise, run this before requesting the production cert.

— Decide whether the precertificate's existence is itself sensitive. CT publishes the full subject and all SAN (Subject Alternative Name) entries; a wildcard or a codename hostname leaks intent days early.
— If it leaks, request a wildcard (*.example.com) so the specific hostname never enters a log.
— Pre-query crt.sh and Censys for your apex domain to record the current baseline set of logged certs.
— Confirm your CA submits to at least two independent logs from distinct operators; Chrome's policy requires this for SCT (Signed Certificate Timestamp) acceptance.
— After issuance, verify the embedded SCTs with openssl x509 -text and check each log's Maximum Merge Delay (24h typical) has elapsed before you assume inclusion proofs exist.

Evidence vs. speculation: SCTs are a promise of inclusion, not proof; only an audited inclusion proof confirms the log kept its word.

Further reading: RFC 9162, sections 3 and 5; Chrome CT Policy.

Bottom line: treat CT as a publication event you schedule, not a side effect you discover.