Certificate monitoring

The Certificate module shows a days-left ring, the expiry date, the issuer, when the certificate was last read, and every watched subdomain's own certificate soonest-to-expire first. Behind it is a full reading of what your server actually hands to a visitor.

Where the reading comes from

Our scanner connects to your server the way a browser does, completes a TLS handshake, and reads the certificate it's given. That happens from our own scanner (a private container we run on Cloudflare), not from a third-party service, and it needs no key or account anywhere.

It reads, once a day:

• the domain itself and www on port 443;
• every watched subdomain on port 443;
• the other ports that start with TLS where the port scan found something listening, such as 8443 on a UniFi controller or 993 and 995 on a mail server.

It also reads the domain again after you press Scan now (usually within a couple of minutes) and when you add a domain. Daily reads run for domains on a plan that includes automatic monitoring; on Free, a manual scan is what triggers one.

If your site is behind Cloudflare, the reading is Cloudflare's edge certificate. That is correct: it's the certificate your visitors get.

We used to work this out from Certificate Transparency logs, the public record of every certificate an authority issues. Those logs say what was issued, not what your server is using, and the guess was wrong often enough (a backup certificate your CDN never serves, an old host's certificate that's still valid) that we stopped. The Certificate module now shows only what a server actually presented.

What each reading checks

We also record the issuer and the intermediate that signed it, every name on the certificate, the key type and size, the signature algorithm, the newest protocol the server agreed to, and whether it staples an OCSP answer. Not stapling is normal (Let's Encrypt stopped offering OCSP in 2025), so it's shown as a fact, never as a problem.

Each problem becomes a row in the security checkup under SSL/TLS & Website, grouped so one setting behind twelve hostnames is one row that lists all twelve. The same readings feed the testssl findings in a vulnerability scan report, in the same words.

CAA record

The checkup also looks up the domain's CAA record, which tells certificate authorities which of them may issue for it. Having none is fine and doesn't affect the score. If you have one and it doesn't allow the authority your site is currently using, the row warns you, because that authority's next renewal will be refused.

Subdomain and service-port certificates

Every host found by subdomain discovery is read on port 443. A host that answers HTTPS but won't hand over a certificate for its name is listed with no expiry, which is the finding. A host that doesn't serve HTTPS at all (a mail-only name, for example) isn't listed, because that isn't a certificate problem.

Service ports follow the port rule: expired is a medium finding there, since the website itself still works, and the name-mismatch and trust checks apply the same way.

Each of these certificates alerts on its own, on the same ladder as the site's (60, 30, 14 and 1 days inside your SSL expiry threshold, and once expired), with the quiet rule below. Ports on one host serving the same certificate share one alert; a host that stopped answering keeps its last reading but raises nothing.

The quiet rule for auto-renewing issuers

A certificate from Let's Encrypt, ZeroSSL, Google Trust Services, Buypass, Cloudflare or Amazon is renewed by a client that runs on its own, so a countdown on one is noise. For those issuers the module, the domain's findings, the widget and the server's expiry emails say nothing until the certificate has one day left, the one day that means renewal has failed.

Hand-renewed certificates (a paid certificate from another authority) get the normal warnings: 14 days or fewer is urgent, and on the website 30 days gets a planning note. The SSL expiry notification threshold in Settings defaults to 14 days.

When the scanner can't reach a host

A timeout or a refused connection says nothing about the certificate, so it never clears one. The last certificate that was read keeps showing, marked with the date it was read, for up to seven days. After that the module shows it as not read rather than showing a week-old guess.

For developers

GET /api/domains/:id/certificates returns every endpoint's reading (chain, key, protocols, problems) as the scanner last saw it. The same data sits in each scan's payload as certificate (the domain on 443) and tls_endpoints (everything else).

Common questions

My host renewed yesterday and the module still shows the old date. The daily read picks it up within a day. Press Scan now to read it sooner; if it still shows the old certificate, the server is still serving it, usually because the web server wasn't reloaded after the renewal.

The app's handshake issuer differs from the module. The iOS app also does its own handshake during its reachability check. If the two disagree, your phone and our scanner were handed different certificates, which usually means a load balancer or CDN with more than one copy.

Why does it say TLS 1.0 is still on? I never turned it on. Many hosts and Cloudflare leave it on by default. On Cloudflare, set SSL/TLS, Edge Certificates, Minimum TLS Version to TLS 1.2.

Why is my Let's Encrypt certificate not warning me at 7 days? Because it isn't supposed to. If it reaches one day, the renewal client has stopped working, and that's when the alert fires.