SSL Certificate Checks

Every HTTPS connection begins with a question: "Are you really who you claim to be?"

The SSL/TLS certificate provides the answer. It encrypts the connection, yes, but more fundamentally it proves identity. When that proof fails—expired certificate, broken trust chain, revoked credentials—browsers display warnings that send visitors fleeing. SSL certificate checks verify this proof continuously, alerting before problems reach users.

What Certificate Checks Actually Verify

A certificate is a bundle of claims. Monitoring verifies each claim holds true:

Expiration Date: Every certificate has a death date. Modern certificates live 90 days (Let's Encrypt) to one year. The check is simple math: how many days until this certificate becomes worthless? Alert at 30 days, again at 14, again at 7. Increasing urgency as the deadline approaches.

Domain Name Matching: The certificate must name the domain you're accessing. A certificate for example.com won't work for www.example.com unless both names appear. This isn't pedantry—it's the entire point. Anyone can claim to be example.com. The certificate proves it.

Trust Chain: Your server's certificate doesn't stand alone. It links to an intermediate certificate, which links to a root certificate that browsers trust implicitly. Break any link and the whole chain fails. The server must present this chain correctly—server certificate first, intermediates next, in order.

Revocation Status: Certificates can be invalidated before they expire. Private key stolen? Certificate Authority made a mistake? The certificate gets revoked. Monitoring checks that your certificate hasn't been added to the revocation list.

Signature Validity: The cryptographic signature must use algorithms browsers still trust. SHA-1 is dead. Weak RSA keys are dead. The certificate must prove its claims using math that hasn't been broken.

Why Certificates Expire

Expiration seems like a burden, but it's a security feature:

Limiting Damage: If someone steals your private key today, the damage ends when the certificate expires. Shorter lifetimes mean smaller windows of vulnerability.

Forcing Review: Expiration forces you to periodically touch your security configuration. Ancient, forgotten certificates can't persist indefinitely. Someone has to look at this, at least once a year.

Enabling Evolution: Cryptographic standards strengthen over time. Expiration creates natural moments to upgrade—new certificate, new algorithms, stronger keys.

The cost is operational burden. Someone must track certificates, request renewals, install new ones. Forget this process and your site goes dark.

Trust Chains Break in Subtle Ways

Certificate chains fail in ways that work in one browser and break in another:

Missing Intermediates: Your server must send the complete chain from your certificate to the root. Forget an intermediate certificate and some browsers trust you while others don't. Chrome might work fine while older Android devices refuse to connect.

Expired Intermediates: Your certificate is valid, but the intermediate certificate in your chain expired. The chain breaks even though your certificate looks fine in isolation.

Wrong Order: Certificates must appear in sequence—server certificate, then intermediates. Scramble the order and some clients get confused.

Different Trust Stores: Chrome, Firefox, Safari, and various operating systems trust different root certificates. A chain valid everywhere else might fail on that one Linux distribution your biggest customer uses.

The Revocation Problem

What happens when a certificate needs to die before its time?

Certificate Revocation Lists (CRLs): Certificate Authorities publish lists of revoked certificates. The problem: these lists grow large, updates lag, and clients must download them.

OCSP (Online Certificate Status Protocol): Query a server for real-time revocation status. Better freshness, but adds latency to every connection and reveals your browsing habits to the OCSP server.

OCSP Stapling: The server queries OCSP itself and attaches the signed response to the TLS handshake. Fresh revocation data without the privacy leak. This is the right answer when it works.

Must-Staple: A certificate extension requiring OCSP stapling. If the server can't provide a stapled response, browsers reject the connection entirely. Maximum security, but one misconfiguration and you're offline.

Protocol Configuration Matters Too

The certificate is necessary but not sufficient. The server's TLS configuration can still fail:

TLS Version: TLS 1.2 minimum. TLS 1.3 preferred. Anything older (TLS 1.0, SSL 3.0) has known vulnerabilities. Monitoring can verify you're not accidentally offering ancient, broken protocols.

Cipher Suites: The server must support strong ciphers while refusing weak ones. Monitoring verifies you offer appropriate options and reject deprecated ones.

Forward Secrecy: Perfect Forward Secrecy ensures that stealing your private key today doesn't decrypt yesterday's traffic. Monitoring verifies PFS cipher suites are available and preferred.

Key Strength: 2048-bit RSA minimum, or 256-bit ECDSA. Weaker keys are mathematically vulnerable. The certificate might be valid but the key behind it too weak to trust.

Certificate Transparency Changes Everything

Certificate Transparency (CT) logs create public records of every certificate issued:

When a Certificate Authority issues a certificate, it's logged publicly. Browsers require Signed Certificate Timestamps (SCTs) proving the certificate appears in these logs. This creates accountability.

The real power: you can monitor CT logs for unexpected certificates. If someone fraudulently obtains a certificate for your domain—a compromised Certificate Authority, a social engineering attack—the CT logs reveal it. You'll know someone else is claiming to be you.

Let's Encrypt Changed the Game

Let's Encrypt removed every excuse for not using HTTPS:

Free: No cost barrier. Any site can have a valid certificate.

Automated: The ACME protocol handles everything—validation, issuance, renewal. Tools like Certbot make this one command.

90-Day Validity: Here's the clever part. Ninety days is deliberately too short for comfortable manual renewal. Let's Encrypt made this choice to force automation. If you're renewing manually every 90 days, you're doing it wrong. The short lifetime is a feature: it pushes everyone toward automated renewal, which is more reliable than human memory.

But even automated systems fail. Network changes block validation. DNS misconfigurations prevent challenges. API rate limits kick in at the wrong moment. Monitoring catches failed automation before the certificate expires.

Common Failures and What They Mean

Name Mismatch: "This certificate is for example.com, but you're visiting www.example.com." Get a certificate covering both names, or redirect users to the covered name.

Expired Certificate: Past the validity date. Renew immediately. If automation was supposed to handle this, find out why it didn't.

Untrusted Issuer: The chain doesn't reach a trusted root. You're probably missing intermediate certificates, or using a Certificate Authority browsers don't trust.

Self-Signed Certificate: The certificate vouches for itself—no external authority confirms the identity. Fine for testing, not for production.

Revoked Certificate: The Certificate Authority invalidated this certificate. Find out why (key compromise? validation problem?) and get a new one.

Monitoring Strategy

Discover Everything: Don't rely on someone's spreadsheet of certificates. Scan your infrastructure. Forgotten certificates on forgotten servers cause surprise outages.

Check Daily: Verify certificates every day. This catches problems quickly and reveals trends—that certificate that expires in 45 days today will expire in 44 days tomorrow.

Check From Outside: Monitor from the Internet, not just your internal network. See what users see. Catch CDN certificate issues, DNS problems, firewall misconfigurations.

Validate Everything: Expiration is just one failure mode. Check trust chains, domain matching, revocation status, protocol configuration. A certificate can be unexpired and still broken.

Actually Connect: Don't just examine the certificate file—connect to the service and complete a TLS handshake. Configuration problems that look fine on paper fail in practice.