What actually happens when a TLS certificate expires (and how I built a Bash guardrail for it)

Jesica Kearney — Sat, 12 Sep 2026 17:51:20 +0000

Every few months, somewhere, a website goes down for the most avoidable reason in infrastructure: a TLS certificate expired and nobody was watching. Browsers throw a full-screen red warning, API clients refuse to connect, and an on-call engineer gets paged for something a calendar reminder could have prevented.

I've dealt with enough certificate issues in production to want a lightweight guardrail I fully control — so I built one in Bash, rather than reaching for a managed service that hides the mechanics. It's a small tool, but it's a good excuse to walk through what a certificate actually is and why expiry is only half the problem.

A certificate is a public identity document

A website's certificate is public by design. When a client connects over HTTPS, the server presents its certificate to anyone who asks — before any encryption begins — because the certificate is how the server proves it is who it claims to be.

You can see this yourself. This one command opens a TLS connection and reads the certificate's expiry date:

echo | openssl s_client -servername github.com -connect github.com:443 2>/dev/null \
  | openssl x509 -noout -enddate

No login, no API key. The certificate carries only public metadata: the domain it was issued for, the issuing authority, the public key, and the validity window. The private key never leaves the server. That split is the whole basis of TLS — anyone can verify the server's identity, but only the server can prove it.

The handshake, step by step

Checking a certificate is just performing the opening moves of a normal HTTPS connection:

TCP connect to the host on port 443, exactly as a browser would.
ClientHello + SNI. The client signals it wants to speak TLS, and the -servername flag sets SNI (Server Name Indication) — because many sites share one IP address, SNI tells the server which site's certificate to present. Omit it and you can be handed the wrong certificate entirely.
The server presents its certificate in the clear.
Parse the notAfter date and compute days remaining.

A browser would continue from here into an encrypted session; the check just reads the date and disconnects.

Expiry is only one of the checks

Expiry is the obvious failure mode, but it's only one of several independent checks a browser runs. A certificate can be perfectly in-date and still be rejected — because it was issued for the wrong hostname.

The clearest example is a wildcard-scope mismatch. A *.badssl.com certificate is valid, but wildcards match only one level, so it does not cover wrong.host.badssl.com. Other common causes in the wild:

Shared IP / wrong default cert — a missing SNI default hands you another site's valid certificate.
Reused certificate — a cert deployed onto the wrong host by mistake.
CDN / load-balancer gaps — a new subdomain pointed at infrastructure whose certificate doesn't include it yet. In every case the browser hard-blocks the connection, because a valid certificate belonging to someone else is exactly what a man-in-the-middle attack looks like. Expiry checks miss all of these, so hostname matching has to be a separate check:

bash
openssl s_client -servername "$domain" -connect "$domain":443 \
  -verify_hostname "$domain"

This returns Verify return code: 0 (ok) on a match, or 62 (hostname mismatch) when the certificate is real but wrong for that host.

Turning a script into infrastructure

A script that prints text is a toy. What makes it usable by real systems is exit codes. This one follows the Nagios convention:

Code    Meaning
0   All certificates OK
1   Warning window, or a hostname mismatch
2   Critical, expired, or unreachable

That single design choice is what lets a scheduler act on the result without parsing any text. Wired to a GitHub Actions cron, it needs no extra tooling: because the script exits non-zero on trouble, a failing certificate turns the workflow run red — and that red status is the alert.

Why build what you could buy

Some companies offer certificate monitoring as a checkbox, so building it by hand isn't about saving money. The value is owning every layer under that checkbox — the handshake, SNI, the public/private key split, why hostname verification is separate from expiry, and how exit codes turn a script into something a monitoring system can consume. When the managed version misbehaves, that's the difference between debugging it and filing a support ticket.

The full tool — including a companion process/inode inspector — is on GitHub:[https://github.com/JayKearney/linux-toolbox]. Feedback and questions welcome.

DEV Community: Jesica Kearney

What actually happens when a TLS certificate expires (and how I built a Bash guardrail for it)