Documentation

Hear about a certificate before it expires

An expired certificate takes a site down as thoroughly as a crashed server: every browser refuses the page and every API client refuses the connection. It is rarely anyone's fault on the day. A renewal job stopped months ago, a DNS change broke a challenge, or the new certificate reached one load balancer and not the other. A TLS check tells you while there is still time to fix it.

What it checks

On every run the check connects to the host and port you name, completes a TLS handshake and judges what it received:

The earliest expiry in the chain counts, not only the server certificate's: an intermediate that expires first breaks the site on its own date. The trust check uses only the certificates the server sends. Desktop browsers sometimes repair a missing intermediate from their cache, but API clients, command-line tools and older phones do not, and they are the clients you would not hear from.

A server can hold two certificates, typically an ECDSA one and an RSA one, and shows the RSA one only to clients that cannot use ECDSA. The daily configuration test asks for each kind, and every certificate it receives is checked like the main one: validity, trust, name and expiry, on every run. A finding about it names the certificate. A server that speaks only TLS 1.3 encrypts its certificates, so a second one stays unseen, and the result says so.

Each result records what the server presented, even when a check fails: subject, issuer, names, key, expiry dates and the key pins an app can use for certificate pinning.

Revocation, Certificate Transparency and CAA

Revocation is checked for the server certificate, from an answer the server staples to the handshake, or else from the CA's revocation list or OCSP responder. Only an answer signed by the issuing CA and still current counts; anything else reads as unknown, and an unknown answer never fails a check, because a CA's server being down is not your site being down.

Certificate Transparency follows the rules Chrome applies: a publicly trusted certificate has to carry proofs from independent public logs. Certificates from your own authority are exempt, as they are in browsers.

CAA records name the CAs allowed to issue certificates for a domain. When they no longer include the CA that issued the current certificate, the check warns: the certificate still works, but its renewal will be refused. A name with no CAA records is noted in the result without changing its status.

Pinning for mobile apps

A mobile app that pins keys refuses a server whose chain no longer carries one of them, while every browser keeps working, so the failure reaches you through app reviews. Set the same pins on the check, in the format apps use (sha256/ and the key's hash), and a renewal that changed the key fails here first. Each result lists the pins of the chain it saw, ready to copy.

When the certificate changes

Each check remembers the certificates it was served over the last 30 days. When a location is served one the check has not seen in that time, it records the change and, by default, tells you if it looks unexpected: the new certificate was issued by another organisation, covers fewer names or has a weaker key than the one it replaced, or the server's lock grade dropped with it. A routine renewal by the same CA stays quiet, unless you choose to hear about every new certificate; you can also turn these notices off. Comparing against the last 30 days, not only the last result, stops a CDN whose edges serve different certificates from raising a change on every run.

The notice goes to subscriptions with the Certificate changed trigger, by email, webhook or in the app, and names the location and both certificates.

The defaults, and why

A new TLS check warns 14 days before expiry and fails 3 days before. Automated renewal normally happens about a third of a certificate's lifetime ahead, so at 14 days renewal is already overdue, and 3 days of failing leaves time to fix it by hand. Both are per check, so a certificate from an internal authority on a yearly cycle can have its own numbers.

The check runs every 6 hours, and its locations take turns: with four locations, each one checks once a day. What a TLS check finds changes over hours and days, not seconds. Whether the site is up at all is the job of an HTTP check every few minutes, and the two work best side by side.

When the server cannot be reached

If three attempts get no reply, the result is marked unknown, with the reason. It does not judge the certificate, and it never turns an earlier failure into a pass: a location that last saw an expired certificate stays failing until it sees a good one.

Other ports and internal certificates

Any port that starts in TLS can be checked, such as 465 or 993 for mail. If the host is an IP address, or serves several names, set the server name to the one the certificate should cover. For a certificate from your own authority, turn off chain verification: expiry and hostname are still checked. The HTTP checks below run by default on port 443 only; the check's settings switch them on for HTTPS on another port, or off.

HTTP headers

On port 443 the daily configuration test also reads the HTTP headers that protect HTTPS: Strict-Transport-Security, the redirect from port 80 and the Secure attribute of cookies. A missing or too-short HSTS header counts against Mozilla's guidelines like any other configuration finding; the rest are recorded and count towards the lock grade's fifth lock. Cookie values and redirect targets are never stored.

What our checks send

A TLS check is an ordinary client connection, like a browser's. It reads what the server presents and closes. Once a day for each server and location it also tests the server's configuration with up to 60 short test connections and, on port 443, requests the home page once over HTTPS and once over plain HTTP on port 80, reading only the headers and following no redirect. Our page for server operators lists the addresses the checks come from: https://pingsured.eu/bot