Check what is served, not what is configured
The certificate in your configuration and the certificate on the wire are different things, and the gap between them is where outages live. A renewal can succeed on disk while the running process keeps serving the old one from memory because nothing reloaded it.
That is why an external check matters. It observes what a real client sees, from outside your infrastructure, with no assumptions about your deployment pipeline.
What to look at beyond the expiry date
- Chain completenessA valid leaf with a missing intermediate works in browsers that cache it and fails in stricter clients like curl and mobile SDKs.
- Hostname coverageConfirm the SAN list actually includes the host being served. Wildcards do not cover multi-level subdomains.
- Issuer changesAn unexpected issuer can indicate a misrouted request or an interception proxy.
- Validity windowCertificate lifetimes keep shortening. Renewal automation that worked at 90 days needs revisiting as windows narrow.
How the checker works
A browser cannot read another site's certificate, so the lookup runs on our server. It resolves the hostname, refuses anything that is not a public address, then opens a TLS connection on port 443 (or 8443 if you add :8443) with the hostname sent as SNI, exactly as a browser would. It reads the certificate the server presents, validates the chain against the standard trusted root store, and checks the hostname separately, so a chain problem and a name mismatch are reported independently. The connection gives up after five seconds.
How to read the result
- Days remainingWhole days until the Valid to date. Under 30 days, renewal should already be in progress; under 7, treat it as urgent. An expired certificate shows how many days ago it lapsed.
- Chain“Trusted” means a recognised certificate authority issued it and every link verifies. “Not trusted” comes with the reason, most often a missing intermediate, a self-signed certificate or an expired one.
- Hostname matchWhether the certificate covers the exact name you entered. If not, the SAN list shows the names it does cover, which usually points to the wrong certificate on a shared IP.
- ProtocolThe TLS version negotiated, such as TLSv1.3 or TLSv1.2. TLS 1.0 and 1.1 are deprecated and refused by current browsers.
A worked example
Say you check shop.example.com and see a Let's Encrypt certificate with 24 days remaining. Let's Encrypt certificates last 90 days and the usual clients (certbot included) renew them when about 30 days are left. A certificate with 24 days left should therefore already have been replaced, which means renewal is failing or the new certificate was never loaded. Check the renewal logs and whether the web server was reloaded, then look again: a healthy setup shows roughly 89 days right after renewal.
The same reasoning works for any issuer. Know your renewal point, and treat a certificate that has passed it as a failed renewal, not as “still fine”. Our guide to SSL certificate expiry covers the usual causes, and the domain expiry guide covers the registration that sits underneath the certificate.
A manual lookup confirms the certificate is fine right now. It does nothing about the renewal that will silently fail in eleven weeks. Continuous checking is the only version of this that actually prevents an outage.
Watching certificates continuously
In SutramX there is no separate SSL monitor to set up. Every HTTP and API monitor for an https:// URL validates the certificate on each check, so an expired, self-signed, revoked or mismatched certificate fails the check and opens an incident like any other outage. The monitor's Domain & SSL card shows the expiry date, issuer and any chain problem, plus the domain's registration expiry and registrar.
Turn on expiry reminders on that card and choose how many days ahead to start (1 to 90, default 30). After the first notice, reminders follow at 15, 7 and 2 days and 24 hours before expiry, and for three days after if nothing was renewed. They go to your chat channels and webhooks, and by email once the SSL Certificate Expiry preference is on. Details are in the SSL & domain expiry docs and on the SSL monitoring feature page.
Frequently asked questions
Why does my browser say the certificate is fine when this checker says the chain is not trusted?
Browsers remember intermediate certificates from other sites and can fetch a missing one themselves, so they hide a broken chain. curl, mobile apps, API clients and many monitoring tools do not. If the chain is not trusted here, configure your server to send the full chain (the leaf plus every intermediate) rather than the leaf certificate alone.
How is days remaining calculated?
It is the time from now until the certificate's Valid to date, rounded down to whole days. A certificate that expires in 20 hours shows 0. Dates are shown in UTC.
Can I check a server on another port or on my private network?
Only ports 443 and 8443, and only public hostnames. Private, loopback and link-local addresses are refused, so the checker cannot be used to probe internal networks. For internal services, check the certificate from inside your network.
Why did a second lookup return the same result straight away?
Each host and port is looked up at most once a minute, and repeat lookups in that minute get the saved answer. If you have just deployed a new certificate, wait a minute and check again.
Does SutramX monitor certificates on the Free plan?
Yes. Every HTTP and API monitor for an https:// URL validates the certificate on each check, and expiry reminders can be turned on for any of them, on every plan including Free.
Related tools: the DNS checker to confirm a hostname points where you expect, and the website uptime checker to test the site itself.