An expired certificate is one of the few site failures that visitors see before you do. A browser stops on a warning page, and every API call that validates the chain fails. A TLS certificate check costs under a second per host and removes most of that risk.
The certificate data is public. The TLS certificate API reads it from the outside, the same way a browser does, and returns the dates, the chain, the supported protocol versions and a quality score.
curl -s "https://api2.globus.studio/v2/ssl?domain=example.com&full=1"Step 1: read the expiry date
days_left is the number that matters. Everything else describes the certificate that exists today; the expiry date decides whether it exists tomorrow.
Set two lines. Thirty days is a warning: a renewal window is open and nothing has happened yet. Seven days is an incident: the renewal is late, and someone should be looking at the automation. A certificate that renews itself can still fail quietly, because the old file stays valid until the last day.
Compare TLS certificate check results against a calendar, not against the last run. A monitor that stops running reports nothing, and nothing looks the same as success.
Step 2: look at the chain
The chain array lists every certificate between the host and the root. A missing intermediate certificate is a common misconfiguration: some browsers repair the chain from a cached copy, others refuse, and the failure looks random to the user.
chain_length of two or three is normal. A TLS certificate check also reports the expiry of each link, which catches the case where a renewed leaf certificate still sits behind an intermediate that is about to expire.
Step 3: ask which protocols the host still accepts
protocols_supported is four booleans, one per TLS version. TLS 1.0 and TLS 1.1 are retired by every major browser. A host that still accepts them can be pushed to a weaker cipher by an old client, and one TLS certificate check shows that in a single field.
Do not stop at “1.3 is true”. The interesting question is whether the old versions are also true. A server that accepts 1.0, 1.1, 1.2 and 1.3 looks modern at the top and is weak at the bottom.
Step 4: read the grade as a checklist
quality scores five things out of 100: days left, signature hash, protocol version, key size and organisation in the certificate. A free domain-validated certificate has no organisation, loses those points and lands at 75. That is the normal ceiling for Let’s Encrypt, not a defect.
A grade of D almost always means one of three things: a protocol that should be off, a key that is too short, or a certificate about to expire. Fix the cause, then run the TLS certificate check again and read the number.
What a TLS certificate check does not do
It does not scan for vulnerabilities, and it says nothing about HSTS, CSP or mixed content. It reports the certificate a public host presents, nothing more.
The endpoint deliberately reports invalid and expired certificates instead of refusing to connect, so a monitor still receives the date on a broken host. That also means a successful response with valid: false is the expected answer for an expired site, not an error to retry.
Put the TLS certificate check on a schedule
The route sits in the heavy group with a limit of 20 requests per minute, and a 429 carries Retry-After. For a hundred hosts, spread the calls over the minute instead of firing them in parallel.
Certificates change a few times a year. A daily TLS certificate check is enough, and the output is small enough to keep: store the date, the days left and the chain length per host. A chart of days_left across a month shows a renewal that never happened before the browser does.
Related reading
For the registration dates behind the domain, see the domain age check. The WHOIS lookup guide covers the registry record itself, including the nameservers that point at the host.
Further reading: RFC 8446, TLS 1.3 and the MDN guide to transport layer security.