SSL certificate monitoring tools: watch the issuer, not just the expiry date

Most SSL certificate monitoring tools do one job: count the days left until the expiry date. That check stayed green through the October 2026 eMudhra incident, while Firefox and Chrome began rejecting certificates that were still months from expiring. Pick a monitor by whether it also watches who issued your certificate - and automate renewal before the maximum validity drops again.

Here is what changed, what each kind of tool can actually see, and the five checks worth paying for. Upfynd lists 144 products in Testing & Monitoring and 139 in Security as of October 2026; the tools below are judged only on what their own documentation says they check, because we have not tested them ourselves.

The shortlist, by what each tool checks

In our view the split is clean: an uptime monitor tells you when a certificate is about to lapse, and a Certificate Transparency monitor tells you what is being issued in your name and by whom. Most teams need one of each, and the second is the check these products' own documentation mentions least.

What the eMudhra distrust broke that an expiry monitor cannot see

On 17 October 2026 at 20:06 UTC, Mozilla received a report through the Chrome Root Program that the private keys of eight eMudhra intermediate CAs had been compromised, with proof of key control attached. Mozilla recovered the private keys itself 100 minutes later and completed distrust via OneCRL the same evening, at 22:59 UTC. Mozilla's analysis in that bug is blunt about the cause: the affected P-384 private keys were tiny integers, all below 256, so they were trivially recoverable.

eMudhra revoked all eight intermediates with reason `caCompromise` on 18 October, and Mozilla shipped an unscheduled Firefox update on 20 October. Mozilla then went further and emergency-removed trust in the emSign ECC Root CA - G3 root, because clients that do not check revocation would otherwise keep accepting the chain. The same bug thread records that Chrome planned to drop the root in Chrome Root Store v43, expected in Stable on 27 October 2026, and puts roughly 30,000 certificates - most of them issued over ACME - in need of migration to a different hierarchy.

Four days later eMudhra's board decided to withdraw from the global SSL/TLS certificate business entirely, a business it says was about 1% of its global revenue. Its announcement promises to replace affected certificates at no cost through partners, and to keep revocation and certificate status services running until every issued certificate has expired or been replaced.

Now read that back from the point of view of a dashboard. Every one of those certificates had a valid date range. A monitor whose only question is "how many days until notAfter?" reported no problem on 17 October, no problem on 20 October, and no problem on the morning your users started seeing interstitials. The failure was upstream of the certificate, in the trust store.

SSL certificate monitoring tools: the five checks that matter

Rank candidates by how many of these they perform, not by how many notification integrations they list.

1. Expiry. Days until `notAfter`, with alerts early enough to renew by hand if automation fails.
2. Chain and hostname. Is the full chain served, in order, and does the certificate match the hostname? Both break on deploys, not on a schedule.
3. Revocation and trust-store status. Is the issuing intermediate on a browser blocklist, and is the root still in the Mozilla, Chrome, Apple and Microsoft programs? This is the check that mattered in October.
4. Issuance visibility. What certificates exist for your domains, and which CA issued each one? Certificate Transparency logs answer this; your server does not.
5. Renewal automation. ACME issuance you can re-run in one command, so switching CA is a configuration change rather than a project.

Check three deserves a caveat, because it is the one buyers assume they have. Distrust is largely delivered as software: Mozilla pushed the October blocklist in a Firefox update, and removed the root outright to protect clients that do not check revocation at all. So the thing that decides whether your users break is the update cadence of every trust store in front of them - browsers, container base images, language runtimes, load balancers - and no external monitor can see inside those. The honest version of check three is a monitor that names your issuing chain, plus your own list of where that chain is trusted.

We would treat checks one and two as table stakes, and they are widely available. Checks three and four are where the market thins out. Check five is not monitoring at all, but it is what turns an alert into a ten-minute fix.

What hosted uptime monitors actually promise

UptimeRobot's help center says the expiration check runs once every 24 hours, with default reminders at 30, 14, 7 and 0 days before expiry that you can edit by specifying any number of days. The first warning depends on the issuer: 14 days out for Let's Encrypt and Cloudflare certificates, 7 days for cPanel-issued ones. The same article says a detected SSL error - expired, invalid or improperly configured - flips the monitor to DOWN, and that monitors with SSL error checking enabled now go down with "SSL Host-Mismatch" when the certificate was issued for a different hostname. The limit worth knowing before you plan around it: SSL monitoring is available on paid plans, and free-plan HTTPS monitors are not checked for certificate issues. The article was last modified on 21 October 2026.

Better Stack puts certificate monitoring in the Advanced settings of an uptime or keyword monitor, and its docs state plainly that certificate expiration alerts require a paid plan. Its documentation describes expiration alerting and does not mention chain-of-trust, revocation or hostname validation, so we would not assume those are covered. Both products are worth having for what they are - uptime monitoring with a certificate clock attached - and neither is a substitute for check three or four.

The tool that would have caught October

Cert Spotter from SSLMate is built around the logs rather than the endpoint. Its own page says it monitors Certificate Transparency logs and alerts you when an unauthorized certificate is issued, that its Unknown Certificate Alerts flag certificates from untrustworthy issuers, that Expiration Monitoring warns when certificates have not been renewed, and that Installation Monitoring checks the chain, hostname matching and OCSP stapling. Pricing starts at $15/month on the Hobbyist plan for up to 20 endpoints with hourly health checks, rising to $100/month for 150 endpoints at 15-minute checks; there is a 30-day free trial and no permanent free tier listed, as of October 2026.

We would skip it if you run a handful of domains all issued by one ACME provider and you already know which CA that is. Its value is inventory: knowing that 30,000 certificates across your estate came from a CA you had never heard of is the problem Cert Spotter exists to solve, and the eMudhra case - where many affected subscribers inherited the CA through an intermediary - is exactly that shape.

Free and open source SSL certificate monitoring

Self-hosting changes the trade-off from money to maintenance. Uptime Kuma is MIT-licensed, runs from a single `louislam/uptime-kuma:2` container on port 3001, and lists "Certificate info" among its features - but its README does not document expiry-alert thresholds, so confirm the behavior in the dashboard before you rely on it. openstatus is AGPL-3.0, offers a managed service or self-hosting, and checks from 28 global regions across three cloud providers, with private locations in an 8.5MB Docker image; its README lists no certificate checks, so treat it as an uptime tool. Upfynd lists 211 open source products as of October 2026, and the same rule applies here as in picking a vulnerability scanner by the layer it can see: the question is not whether the tool is free, it is which layer the tool is looking at.

How long are SSL certificates valid in 2026, and why that changes your tooling

The CA/Browser Forum's Baseline Requirements set the schedule, and the dates are fixed. The Relevant Dates table gives a maximum validity period for subscriber certificates of 200 days from 2026-03-15, 100 days from 2027-03-15 and 47 days from 2029-03-15. Domain and IP validation data reuse follows the same steps - 200 days, then 100 days, then 10 days in 2029.

Two consequences for tooling. First, in our view a human renewal calendar is already untenable and will get worse: at 47 days a certificate turns over roughly eight times a year. Second, we would read short lifetimes as a quiet mitigation for the exact failure above - the shorter the certificate, the sooner a bad hierarchy ages out of your estate. That argues for ACME everywhere, with a second CA already configured, rather than for more alerting.

What to do this week

1. Inventory issuers, not just expiry dates. For each hostname, record the issuing CA and the root it chains to. If your monitoring cannot tell you this, that is the gap to close first.
2. Check your trust stores, not only browsers. The Mozilla bug notes that non-browser runtimes lag behind; Go and Python bundles shipped their own updates during the October incident. Containers and CI images pin old root bundles for months.
3. Make reissuance boring. If re-issuing every certificate from a different CA is not a single command, we would call that an outage waiting for a trigger rather than an automation backlog.
4. Add one issuance-visibility check. Certificate Transparency monitoring is the only way to learn about a certificate someone else obtained for your domain, or from a CA you did not intend to use.
5. Set alert windows against the new validity floor. A 30-day warning on a 47-day certificate is not an early warning, it is most of the certificate's life.

If you are weighing specific products, start from the Testing & Monitoring category and the Security category on Upfynd, check each vendor's own docs for checks three and four above, and submit a tool if you maintain one that does the chain and revocation work properly.