CT log vs live handshake
Issuance and serving are different events. Monitoring the wrong one misses outages.
What a CT log tells you
Certificate Transparency logs (from crt.sh, Censys, or a CA’s own stream) record that a CA issued a certificate for a name. That is useful for discovering unknown names, catching a mis-issued cert, or seeing that Let’s Encrypt minted a new lineage. It is not a statement that any particular IP, anycast POP, or Kubernetes ingress is presenting that certificate.
What a live handshake tells you
A TLS client connects to a host:port, completes Server Name Indication, and reads the peer certificate. That is what a browser does. It is also what SSLert does. The result includes issuer, notBefore, notAfter, and days remaining for that endpoint, right now.
Where they disagree
- A new cert is in CT, but nginx was not reloaded — CT is green, handshake is old.
- Two certificates exist for the same name (old + new). CT shows both. The balancer still serves one.
- A CDN or Anycast POP is stale in one region. CT cannot see that.
- You monitor
wwwin CT and users hit the apex (or the other way around). - Internal names never appear in public CT. They still expire on the wire.
What to monitor if the goal is “users can connect”
Handshake the names you terminate TLS for. Use CT as an extra signal for inventory and mis-issuance, not as a substitute for the balancer. Let’s Encrypt expiry mail (retired 4 June 2025) was closer to issuance than to serving; it would not have caught a successful renew that never reached nginx.
SSLert’s public checker and the hosted monitor both do the live handshake. They do not scrape CT logs.