There are three different things people mean by "check my SSL cert"

#webdev #security #devops #node

A cert expiring in production is one of those outages that feels avoidable in hindsight. Nobody meant to skip it. It just wasn't anyone's job to check.

The confusing part

"Check my SSL cert" can mean three different things, and they check three different systems.

Is the domain registration itself about to expire? That's a WHOIS/RDAP question, nothing to do with TLS.
Has a new certificate been issued for this domain recently, maybe one you didn't request? That's a certificate transparency log question, a public append-only record of every cert any browser-trusted CA has ever issued.
What certificate is the server actually presenting right now, and how many days until it expires? That's a live TLS handshake question, and it's the one that actually causes an outage when the answer is "zero."

I'd already built tools for the first two. This one covers the third, and it's the one people usually mean when a pager goes off.

How it works

Opens a direct TLS connection to each host, the same handshake a browser performs, and reads the certificate the server presents. Node's built-in tls module does the heavy lifting:

const socket = tls.connect(
  { host, port, servername: host, timeout: 8000, rejectUnauthorized: false },
  () => {
    const cert = socket.getPeerCertificate();
    const authorized = socket.authorized;
    // ...
  },
);

rejectUnauthorized: false looks backwards at first. The point isn't to skip trust checking, it's to keep the connection open long enough to actually read the certificate even when it's self-signed or the chain is broken. socket.authorized and socket.authorizationError still report the trust result separately, so a broken cert shows up as data ("isSelfSigned: true", a trust error message) instead of a connection failure with no detail. Silently failing to connect isn't the same as telling someone their cert is bad.

What it returns

One record per host: issuer, subject, valid dates, days until expiry, expired/self-signed flags, and the trust result. A host that can't be reached at all still returns a record, just with reachable: false and an error message, since "we tried to check and something's wrong" is itself a useful result for a host that should have been reachable.

Pricing shape

Billed per host checked, not per field returned. One charge whether the host is fine, expired, or completely unreachable.

Try it

Source: github.com/timmKal01/ssl-certificate-expiry-checker
Hosted version (Apify actor, no setup): apify.com/m_ctim/ssl-certificate-expiry-checker

If you're already checking domain expiry or watching CT logs, this is the third leg of that stool, the one that actually matches what's live on the wire right now.

DEV Community