Skip to main content
All fixes

SSL, TLS, security headers

Verify SSL certificate appears in Certificate Transparency logs

Browsers reject certificates not logged in CT. Confirm SCTs are embedded or stapled, and monitor logs for unauthorized issuances against your domains.

What's happening

Certificate Transparency (CT) is a public-log system where every publicly trusted certificate must be logged before it is accepted by browsers. Chrome has required SCTs (Signed Certificate Timestamps) since April 2018 on all newly issued certificates; Apple followed in 2018 and Mozilla mandates CT in its CA program. A certificate without valid SCTs is rejected by Chrome with NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED.

SCTs are delivered three ways: embedded in the certificate itself (most common, done by the CA at issuance), via TLS extension during the handshake, or via OCSP response stapling. Most modern CAs embed SCTs at issuance and you do not have to do anything. The issue arises with legacy certificates issued before CT was mandatory or with privately operated CAs that never logged.

The fix is to reissue any certificate without embedded SCTs from a CA that logs by default (Let's Encrypt, DigiCert, ACM, Cloudflare). Beyond the lack-of-SCT failure mode, CT also provides an attack-surface monitoring tool: subscribe to logs and you learn when any CA mints a certificate for your domain — including unauthorized ones.

Why it matters

Chrome and Safari refuse the connection outright with a hard error. Firefox does not enforce CT today but is moving in the same direction. The site appears broken for the majority of users.

CT monitoring is a defensive tripwire: when an attacker convinces a CA to mis-issue a certificate for your domain, the issuance shows up in public logs within minutes. Subscribing to CT logs (via crt.sh, Google's Cloud Logging, or commercial monitors like CertSpotter) is one of the cheapest detection controls available.

Compliance frameworks increasingly reference CT — NIST 800-218 mentions log monitoring, and PCI-DSS 4.0 expects scoped change-tracking on cryptographic identities.

Common causes

  • Legacy certificate issued pre-2018 by a CA that did not log.
  • Private/internal CA used to issue a certificate served on a public hostname.
  • Custom-built certificate that bypassed the CA logging step.
  • CT logging requirement waived by an old browser policy and never reapplied after Chrome enforcement.
  • Certificate served on a host where Chrome's strict CT policy applies (some Google products) without embedded SCTs.

Detect this on your site

Run a quick scan with the SSL Checker. The tool surfaces this exact issue with the records and context needed to apply the fix below.

Open SSL Checker

How to fix it

  1. 1

    Check the served certificate for embedded SCTs

    Run openssl s_client -servername example.com -connect example.com:443 /dev/null | openssl x509 -noout -text | grep -A 4 'CT Precertificate SCTs'. If the section exists with at least two SCTs, the cert is logged. If absent, the cert was not logged at issuance.

  2. 2

    Cross-check via crt.sh

    Visit https://crt.sh/?q=example.com and confirm the certificate is listed. crt.sh aggregates every CT log Mozilla and Google trust. If the cert is present, browsers see it as logged.

  3. 3

    Reissue from a logging CA

    If the cert is not in CT, request a fresh certificate from Let's Encrypt, ACM, Cloudflare, or any other publicly trusted CA — every modern CA embeds SCTs by default. With certbot: sudo certbot certonly --force-renewal -d example.com. Verify embedded SCTs after renewal.

  4. 4

    Subscribe to CT monitoring for your domains

    Sign up at sslmate.com/certspotter, crt.sh email alerts, or a commercial offering. Add every apex domain you own. The monitor emails you when any CA issues a certificate that includes your domain — including unauthorized issuances.

  5. 5

    Set CAA records to constrain issuance

    Combine CT monitoring with CAA records that list only your trusted CAs. The two controls reinforce each other: CAA prevents most unauthorized issuances, CT monitoring catches whatever slips through.

  6. 6

    Document the response process

    Decide in advance how you will respond to an unexpected CT log entry. Steps: validate the issuance against your team, contact the CA's incident response if unauthorized, request revocation, rotate keys if compromise is suspected.

Example

# Check for embedded SCTs in served certificate
openssl s_client -servername example.com -connect example.com:443 </dev/null 2>/dev/null \
  | openssl x509 -noout -text \
  | grep -A 4 'CT Precertificate SCTs'

# Or query crt.sh for CT log presence
curl -s 'https://crt.sh/?q=example.com&output=json' | head -50

Verify a certificate has embedded SCTs and is in public CT logs

Frequently asked

Yes. Let's Encrypt has logged every issued certificate to multiple CT logs since their general availability. The same is true of every CA in the Mozilla and Apple trust stores. The only certificates likely to lack CT entries are private/internal CAs that should not be served on public hostnames.

Usually within minutes — sometimes seconds. CAs submit precertificates to logs synchronously during issuance and crt.sh ingests logs continuously. If a certificate is more than 30 minutes old and not in crt.sh it likely was not submitted at all.

Yes — even short-lived certificates are logged. Monitoring still catches an unauthorized issuance even if the legitimate cert rotates every 60 days. Set the alert to ignore renewals from your known CAs and to flag everything else.

Related fixes

SSL, TLS, security headers

Add CAA DNS records to control which CAs may issue certificates

SSL, TLS, security headers

Limit wildcard SSL certificate scope to reduce blast radius

SSL, TLS, security headers

Fix expired SSL certificate and restore HTTPS access

SSL, TLS, security headers

Renew SSL certificates before they expire and break HTTPS