SSL/TLS Certificate Inspector

Certificate Checks as a Pipeline Gate

Certificate expiry is one of the few outage causes that is entirely predictable and yet still catches teams off guard, which makes it a natural candidate for automation rather than a task left to whoever remembers to check. A common pattern is a scheduled CI job that runs openssl s_client -connect $HOST:443 -servername $HOST </dev/null 2>/dev/null | openssl x509 -noout -enddate against every production hostname, parses the returned date, and fails the build — or pages on-call — if any certificate is inside a 30-day renewal window. Some teams go further and add a pre-deploy gate: before a release rolls out a new load balancer listener or ingress rule, a pipeline step fetches the certificate that will actually be served and checks that its SAN list covers every hostname the new configuration routes to, catching a missing subdomain before it reaches production traffic.

This inspector tool complements that automation rather than replacing it — when a scheduled check fails or a deploy gate blocks a release, pulling the exact PEM block into this viewer gives a human-readable breakdown of what's wrong in seconds, without needing to re-run openssl x509 -text and mentally parse ASN.1 field names.

Why This Belongs in Every SRE's Toolbox

X.509 certificates are the credential that makes HTTPS trustworthy: they cryptographically bind a public key to a domain name, signed by a certificate authority that browsers and operating systems already trust. Every field in that structure — subject, issuer, validity window, Subject Alternative Names, key algorithm — carries operational meaning, but the raw encoding (DER wrapped in Base64, itself wrapped in PEM headers) is illegible without a parser. An inspector decodes that structure into the handful of facts an SRE actually needs during an incident or a routine audit: is this cert valid for the hostname being served, how long until it expires, and does the chain resolve back to a trusted root.

The stakes for getting this wrong are immediate and visible to users: an expired or mismatched certificate produces a full-page browser warning, breaks every API client with strict TLS verification, and — because certificate issues often cascade across load balancers and CDNs — can turn a single renewal failure into a multi-service outage. Building certificate inspection into routine deployment and monitoring workflows, rather than treating it as something you only do when something has already broken, is what separates proactive TLS hygiene from firefighting.

Where Certificate Reviews Go Wrong

• Checking the leaf certificate but not the full chain: a valid leaf served without its intermediate certificate works fine in modern browsers that cache intermediates from prior visits, but breaks for clients that don't — always inspect with -showcerts to confirm the complete chain is actually being served, not just the end-entity cert.
• Relying on the Common Name instead of SANs: browsers have ignored the CN field for hostname validation since 2017 — a certificate with the right CN but a SAN list missing the hostname you're accessing will still fail validation, and inspecting only the CN field misses this entirely.
• Monitoring the certificate file on disk instead of what's actually served: a renewed certificate that a load balancer or nginx process hasn't reloaded will still present the old, soon-to-expire certificate over the wire — check the live endpoint, not the file timestamp.
• Assuming a self-signed or internal-CA certificate doesn't need expiry monitoring: internal service-to-service TLS uses certificates just as capable of expiring silently as public ones, and outages from internal cert expiry are just as disruptive.

Diagnosing TLS Failures Systematically

When a client reports a certificate error, resist the urge to guess and instead pull the exact certificate the server is presenting with openssl s_client -connect host:443 -servername host -showcerts </dev/null 2>/dev/null, then work through a fixed checklist. First, confirm the certificate hasn't expired and isn't presenting a not-yet-valid notBefore date (clock skew on the server can cause this). Second, confirm the SAN list actually includes the hostname the client is connecting to — a wildcard SAN like *.example.com covers one level of subdomain but not a bare apex domain or a second-level subdomain. Third, confirm the chain is complete by counting the certificates returned — if only the leaf is present, the intermediate is missing from the server's configuration.

Fourth, check that the private key on the server actually corresponds to the certificate being served — a mismatched key/cert pair after a botched renewal is a surprisingly common cause of handshake failures. Finally, if everything above checks out, look at protocol and cipher negotiation — an outdated TLS version pinned by an old client library, or a cipher suite mismatch after a security hardening change, can produce errors that look like a certificate problem but are actually a negotiation failure happening before the certificate is even evaluated.

Frequently Asked Questions