SSL/TLS
SSL/TLS certificate monitoring
The SSL/TLS certificate a host actually serves, and how many days it has left.
Try it now
One check, from one place, right now, and nothing is saved. A monitor checks from every location we run and confirms a failure from a second continent before anybody is woken, which a single look cannot show you.
What it is for
Certificate expiry is the outage everybody has had and nobody plans for. Renewal is automated until the day the automation fails quietly, and the first sign is every browser in the world refusing your site at once with NET::ERR_CERT_DATE_INVALID.
This opens a TLS connection on port 443, or wherever you say, and reads the X.509 certificate the host is really serving. That is not always the one your renewal job wrote: a load balancer with one stale node, a second virtual host nobody reloaded, a CDN holding the old chain. It reports the subject, the issuing certificate authority and the notAfter date, so a countdown rather than an up or down.
Wildcard and SAN certificates are one certificate, so watch the host each one is actually served from. A certificate covering *.example.com on three load balancers is three monitors, because the thing that goes wrong is one of the three not being reloaded.
Like every check here, it runs from Amsterdam, New York and Singapore, and a failure is confirmed from a second continent before anybody is woken. How that works.
What you can set
Everything below is on the form when you add one, on every plan.
- Host
- A hostname, a host and port, or a URL: example.com, example.com:8443 and https://example.com all work. Port 443 unless you give one.
You get three warnings: at fourteen days, seven days and two days, each sent once. Daily reminders get ignored, so this doesn't repeat. Thirty days is skipped on purpose: that's when Let's Encrypt renews, so it would fire on every healthy certificate. If the certificate has expired, or we can't read it at all (connection refused, handshake fails, nothing answers), that's an alert, not a warning, and it fires the moment we see it.
Questions
What is the difference between an SSL certificate and a TLS certificate?
Nothing, for this purpose. SSL is the old name for the protocol, TLS is the current one, and SSL 2.0 and 3.0 have been dead for over a decade. The file itself is an X.509 certificate either way, and it does not know which protocol will present it. Most people still search for SSL, so we write SSL/TLS and mean the same thing you do.
Why does my browser say NET::ERR_CERT_DATE_INVALID?
The certificate the browser was handed has expired, or its notBefore date has not arrived yet, which happens when a server's clock is wrong. Chrome shows this code, Firefox says SEC_ERROR_EXPIRED_CERTIFICATE and Safari says the certificate is not valid. This monitor is the thing that tells you two days before your visitors do.
Does this check the certificate chain?
This check reads expiry, so an incomplete chain or a missing intermediate certificate does not fail it. An HTTPS monitor does check the chain: it connects the way a browser does and fails on an invalid chain, a self-signed certificate or a hostname mismatch. Run both on anything that matters, which is why HTTPS is on every plan.
What about wildcard and SAN certificates?
Both work. A wildcard certificate, or one with several subject alternative names, is a single certificate with a single expiry date. What varies is which host is serving it, so add one monitor per host rather than one per name on the certificate.
Do you check OCSP or certificate transparency?
No, and we say so rather than implying otherwise. This reads the certificate a host serves and reports the days remaining. Revocation checking and CT log monitoring are different products solving different problems, and a monitor that half did them would be worse than one that does not.
My renewal is automated. Do I still need this?
That is exactly who this is for. Nobody with a manual renewal forgets for ninety days at a time; the outages come from a Let's Encrypt renewal that failed silently six weeks ago, or succeeded on the machine that writes the certificate and not on the one that serves it.
What if the host does not answer at all?
A TLS handshake failure, a refused connection or a timeout is reported as a failure of the check rather than as an expiry warning, because those are different problems with different fixes. The expiry countdown only moves when we actually read a certificate.