At 2:14 AM on a Tuesday, I got paged for a revenue-critical checkout flow showing a "Your connection is not private" browser error. The cert on our CDN edge layer had expired six hours earlier — at 8 PM, right after the US east coast wound down. The origin cert was fine. Certbot was running. Let's Encrypt had renewed successfully. Nobody had thought to separately monitor the certificate on the Cloudflare custom domain. That outage cost roughly four hours of engineering time and a measurable drop in that night's conversion rate. The fix took 90 seconds once we knew what it was.

That night I built a small monitoring script. Since then I've extended it to cover 50 domains across personal projects, client sites, and internal tooling — all for free. This post documents exactly what I built, why SSL expiry keeps happening even when teams think they've automated it, and how ByteWaveNetwork's SSL Certificate Monitor lets you audit any domain in seconds without installing anything.

Why SSL Expiry Keeps Happening Despite "Automation"

Every engineering team I've talked to says the same thing before an expiry incident: "We had that automated." Here are the four reasons automation fails in practice.

a) Certbot timers silently break

Let's Encrypt renewal relies on either a cron job or a systemd timer running certbot renew. When you update the OS, rebuild a container, or migrate to a new server, the timer doesn't follow. There's no email, no alert, no error — the job simply stops running. The cert renews fine right up until the day the old server was last running, then quietly stops.

b) Wildcard certificates don't auto-renew everywhere

Wildcard certs (*.domain.com) require DNS-01 challenge validation. Not every hosting provider or DNS provider supports the Certbot DNS plugin for your registrar. In those cases the renewal is either manual or silently skipped. I've seen a wildcard cert covering 200 subdomains expire because the DNS provider switched APIs and the plugin started returning 403s — with no alerting.

c) CDN/load-balancer certs are a separate surface

This is the scenario I described above. When you serve traffic through Cloudflare, AWS CloudFront, or a load balancer with SSL termination, there are at least two certificate surfaces: the origin cert and the edge cert. Certbot only renews the origin. The CDN cert is managed through its own console, its own renewal mechanism, and its own expiry clock. Teams monitor origin uptime. Nobody monitors the CDN cert until users start reporting browser errors.

d) SaaS custom domains give you no visibility

If you've added a custom domain to a SaaS product — Webflow, Ghost, Shopify, Notion Sites — the cert is issued and managed by the SaaS platform, not you. You can't check it via Certbot. You often can't even see the expiry date in the dashboard. The only reliable way to know is to connect to port 443 and read the certificate directly.

What the ByteWaveNetwork SSL Certificate Monitor Shows You

I built the SSL Certificate Monitor using the same TLS probe approach we use in the Page Speed Inspector — a Node.js tls.connect() call directly to port 443, no third-party libraries, no external APIs. You enter a domain name. The tool returns a complete certificate report within a couple of seconds.

Here's exactly what the output looks like for a typical domain:

The colour coding is immediate: green means more than 30 days remaining, amber means 8–30 days (renew now), red means fewer than 7 days or already expired. For most teams, the amber band is the action zone — it's visible enough to act on without triggering a crisis.

The Subject Alternative Names section is particularly useful if you have a wildcard or multi-domain cert — you can see exactly which hostnames are covered and immediately spot if a new subdomain you added is actually missing from the cert.

Comparing SSL Monitoring Options

SSL Labs gives the most thorough TLS grading — if you need a full cipher suite audit for a compliance report, use Qualys. ByteWaveNetwork's tool is optimised for rapid daily monitoring and at-a-glance expiry status, not a one-time audit. Screaming Frog will crawl HSTS headers but doesn't surface cert expiry dates in a usable way. The paid uptime services alert you to expiry but don't tell you why — they don't show chain validity, TLS version, or SANs.

SSL Certificate Status Reference

TLS Version Deprecation — Know Where You Stand

Certificate Authority Comparison

For most teams running modern infrastructure, Let's Encrypt plus a solid monitoring setup is the right answer. Where I recommend DigiCert is specifically for OV/EV certificates where the organisation name in the cert itself matters to the business — typically regulated financial or legal services. The cost is the warranty and the assurance process, not the cryptography.

The Free 50-Domain Monitoring Script

Here's exactly what I run. It uses Node.js built-in tls and https modules only — no npm packages. Email goes via Resend's free tier (3,000 emails/month free, which is more than enough for daily cert checks on 50 domains).

// ssl-monitor.js
// Node.js 18+ — no external dependencies except 'resend' for email
// npm install resend

import tls from 'tls';
import { Resend } from 'resend';

const resend = new Resend(process.env.RESEND_API_KEY);

const DOMAINS = [
  'bytewavenetwork.com',
  'yourdomain.com',
  // add up to 50 domains here
];

const ALERT_DAYS = 30;      // amber threshold
const CRITICAL_DAYS = 7;    // red threshold

function checkCert(domain) {
  return new Promise((resolve, reject) => {
    const socket = tls.connect(
      { host: domain, port: 443, servername: domain },
      () => {
        const cert = socket.getPeerCertificate(true);
        const protocol = socket.getProtocol(); // 'TLSv1.3' or 'TLSv1.2'
        const cipher = socket.getCipher();
        socket.destroy();

        if (!cert || !cert.valid_to) {
          return reject(new Error(`No cert returned for ${domain}`));
        }

        const expiry = new Date(cert.valid_to);
        const now = new Date();
        const daysRemaining = Math.floor((expiry - now) / 86400000);

        const sans = cert.subjectaltname
          ? cert.subjectaltname.replace(/DNS:/g, '').split(', ')
          : [];

        resolve({
          domain,
          expiry: expiry.toISOString().split('T')[0],
          daysRemaining,
          issuer: cert.issuer?.O || 'Unknown',
          tlsVersion: protocol,
          cipher: cipher?.name || 'Unknown',
          sans,
          status: daysRemaining < 0
            ? 'EXPIRED'
            : daysRemaining <= CRITICAL_DAYS
              ? 'CRITICAL'
              : daysRemaining <= ALERT_DAYS
                ? 'WARNING'
                : 'OK',
        });
      }
    );

    socket.setTimeout(10000, () => {
      socket.destroy();
      reject(new Error(`Timeout: ${domain}`));
    });

    socket.on('error', reject);
  });
}

async function run() {
  const results = await Promise.allSettled(DOMAINS.map(checkCert));
  const alerts = [];

  for (const result of results) {
    if (result.status === 'fulfilled') {
      const r = result.value;
      console.log(`[${r.status}] ${r.domain} — ${r.daysRemaining}d remaining (${r.tlsVersion})`);
      if (r.status !== 'OK') alerts.push(r);
    } else {
      console.error(`[ERROR] ${result.reason.message}`);
    }
  }

  if (alerts.length > 0) {
    const html = alerts.map(r => `
      <p><strong>${r.domain}</strong> — 
      ${r.daysRemaining < 0 ? 'EXPIRED' : r.daysRemaining + ' days remaining'}<br>
      Expiry: ${r.expiry} | CA: ${r.issuer} | TLS: ${r.tlsVersion}</p>
    `).join('');

    await resend.emails.send({
      from: '[email protected]',
      to: '[email protected]',
      subject: `⚠️ SSL Alert: ${alerts.length} domain(s) need attention`,
      html,
    });

    console.log(`Alert email sent for ${alerts.length} domain(s).`);
  }
}

run();

Schedule it with a daily cron job: 0 8 * * * /usr/bin/node /opt/ssl-monitor/ssl-monitor.js >> /var/log/ssl-monitor.log 2>&1

SSL Certificate Monitoring Checklist

• Check the origin cert expiry date and days remaining.
• Check the CDN/edge cert expiry separately — this is a different cert from your origin.
• Verify TLS version is 1.2 or 1.3. Disable TLS 1.0 and 1.1 if still enabled.
• Check HSTS header is present with at least max-age=31536000.
• Verify the certificate chain is complete — intermediate certs must be included in your server config.
• Check SANs cover all hostnames you're serving — including both apex and www, and any new subdomains.
• Confirm auto-renewal is actually running — check systemd timer status (systemctl status certbot.timer) or cron log output.
• Check any SaaS custom domains (Webflow, Shopify, Ghost) — these are not covered by your server's Certbot.
• Set renewal threshold to 30 days remaining — not 14. Enterprise change management needs the runway.
• After any DNS change or server migration, re-verify all certs from scratch — assume nothing carried over.
• Run a quick check right now on your most critical domain at /tools/ssl-checker/.

Frequently Asked Questions

Why does Let's Encrypt use 90-day certificates instead of one year?

Let's Encrypt deliberately chose 90-day lifetimes to encourage automation and to limit the damage window if a private key is compromised. A stolen key from a one-year cert is exploitable for up to a year; a 90-day cert caps that exposure. The trade-off is that teams who aren't fully automating renewal will hit expiry three to four times per year instead of once. The 90-day design assumes your renewal is automated — if it isn't, you'll feel the shorter lifespan acutely.

What's the difference between a certificate expiring and a certificate being revoked?

Expiry is a scheduled, predictable event based on the NotAfter date embedded in the certificate at issuance. Revocation is an out-of-band action — the CA marks the cert as untrusted before its expiry date, usually because the private key was compromised or the domain ownership changed. Revocation is checked via OCSP or CRL. Most monitoring tools, including the script above, check expiry but not revocation status in real time. If you need revocation monitoring, use Qualys SSL Labs or a dedicated PKI management platform.

How far in advance should I renew my SSL certificate?

The technically correct answer is 30 days before expiry, which is also the window at which Let's Encrypt will accept a renewal request. The operationally correct answer for enterprise teams is earlier — at 45 days if you work in an environment with formal change management, ticket queues, or approval processes. Alerting at 14 days feels early until you factor in a two-week change freeze, a public holiday, or an on-call rotation gap. I alert at 30 days and treat anything under 14 days as a P1 incident.

Can I use this SSL checker to test certificates on non-standard ports?

The ByteWaveNetwork SSL Certificate Monitor probes port 443 by default, which covers the vast majority of public HTTPS traffic. The underlying Node.js tls.connect() approach in the monitoring script can be pointed at any port — useful if you're running HTTPS APIs on port 8443, SMTPS on 465, or LDAPS on 636. For public-facing sites, port 443 is always the right starting point, but the self-hosted script can be adapted by changing the port parameter in the tls.connect() call.

Transparency disclosure: ByteWaveNetwork may earn a commission from affiliate links in this post, including links to third-party services mentioned for comparison purposes. These do not affect editorial recommendations — tools are evaluated on technical merit. The Node.js monitoring script and all ByteWaveNetwork tools referenced are free to use without any affiliate relationship.