tls.cert.sct_missing
No Certificate Transparency (SCT Missing)
What we check
We check every RFC 6962 Signed Certificate Timestamp (SCT) delivery channel: embedded in the leaf certificate, the TLS handshake extension, and the stapled OCSP response. This finding fires when no SCTs are found in any channel.
What this finding means
No Signed Certificate Timestamps were found. The certificate was either not submitted to a public Certificate Transparency log, or the SCTs are not being delivered to connecting clients.
Why it matters
- Reduced transparency. Without CT logging, misissued certificates for your domain would be harder to detect. CT logs are the primary mechanism for domain owners and the security community to discover rogue certificates.
- Unusual for public CAs. All major public CAs embed SCTs by default. A missing SCT may indicate an internally-issued certificate, a very old certificate predating CT requirements, or a CA that does not participate in CT.
- No delivery impact. SMTP senders do not enforce Certificate Transparency — this is an informational finding that does not affect mail delivery.
How to fix
Use a CA that publishes to CT logs. Let's Encrypt and all major commercial CAs embed SCTs automatically — renewing your certificate is usually all it takes:
certbot renew --force-renewal systemctl reload postfixVerify SCTs are present after renewal:
openssl s_client -starttls smtp -connect mail.example.com:25 \ -servername mail.example.com 2>/dev/null | \ openssl x509 -noout -text | grep -A2 "CT Precertificate SCTs"
How it's graded
A missing SCT is informational and carries no point deduction. See Grading Methodology for the full scoring model.
Evidence example
$ openssl s_client -starttls smtp -connect mail.example.com:25 \
-servername mail.example.com 2>/dev/null | \
openssl x509 -noout -text | grep "CT Precertificate"
(no output — no SCT extension in certificate)
TLS handshake extension: no SCTs
Stapled OCSP response: no SCTs