What happened

Certificate Transparency has been effectively mandatory for certificates Chrome trusts since 2018, but "effectively" hid a gap. Chrome required SCTs (the log's signed receipts) at connection time, and a CA could satisfy that by logging the certificate. Several CAs, DigiCert among them, nevertheless offered customers a way to keep specific certificates out of the public logs, typically for internal hostnames or unannounced products, at the cost of those certificates not working in Chrome unless SCTs were delivered another way, such as through a stapled OCSP response.

Two changes in 2026 closed that gap. Chrome 148 (May 5) removed support for SCTs delivered via OCSP stapling, leaving embedding in the certificate or the TLS extension. Then policy v1.8 (June 15) required CAs to log all TLS precertificates and certificates, full stop. DigiCert's knowledge base notice put it plainly: from June 1, DigiCert logs all public TLS certificates, including test and canary certificates, and "every domain name on those certificates becomes publicly visible." There is no reversal; a logged certificate stays logged.

The same policy version tightened other things: new intermediate CA certificates must carry only the serverAuth extended key usage, which is why Let's Encrypt retired its client-authentication certificates over the summer, and mixed-use certificates are being phased out of the public PKI.

Why it matters if you run public infrastructure

For attackers, CT is a free, complete, real-time inventory of your hostnames. Every staging server, every customer-specific subdomain, every "temporary" admin console that got a public certificate is in the logs within minutes of issuance. Reconnaissance tooling has read CT logs for years; the June change removes the last population of certificates that stayed out.

For defenders, it is exactly the same feed, and it is the best one there is. CT answers three questions no internal inventory answers reliably:

  • What hostnames exist under my domains? Including the ones a contractor set up in 2023 and the ones marketing bought a certificate for last week.
  • Who is issuing certificates for my domains? A certificate from a CA you have never used, for a hostname you recognize, is the earliest external signal of a DNS hijack, a registrar compromise or a misconfigured CAA record.
  • Is my renewal automation working? A new precertificate should appear before every renewal. When it does not, the renewal did not happen.

The defenders who lose here are the ones who treated "not in the logs" as a form of privacy. Internal hostnames on public certificates were always visible to the CA, to the log operators and to anyone watching the wire; the change is that now they are visible to everyone. The correct response is to stop putting sensitive names on public certificates (use a private CA, or wildcards where appropriate) and to read the logs yourself before someone else does.

What to check this week

  1. Pull every certificate ever logged for your domains and look at the hostname list as an attacker would. Anything you do not recognize is either forgotten infrastructure or someone else's certificate for your name. Both need a ticket.
  2. Publish CAA records naming the CAs you actually use, so an unexpected issuer is a policy violation and not just a surprise.
  3. Move genuinely internal names off public certificates. Test and canary certificates are now logged too, so staging-payments-v2 tells a story.
  4. Watch the logs continuously, not once. A one-time audit finds the past. The certificate that matters is the one issued next Tuesday for a hostname you never created.

How Attack Surface Scan covers this

Attack Surface Scan reads certificate transparency for every verified domain every 15 minutes. Each new certificate is checked against your authorized-CA list: an issuer you have approved is inventoried quietly, anything else lands in an unknown-certificate queue for review, which is how a hijack or a mis-issuance shows up before its DNS does. New hostnames discovered in the logs are added to monitoring automatically, so the TLS, header, DNS and exposed-service checks run on the whole surface, not just the hosts you remembered to list. With the opt-out gone, that feed is now complete.

Sources