How to Check SSL Certificate Expiry Before It's Too Late

What happens when an SSL certificate expires

The moment an SSL certificate's Not After date passes, browsers reject the connection entirely. Users see a warning like "Your connection is not private" or "NET::ERR_CERT_DATE_INVALID" — with no easy way to proceed. Search engines may also de-index pages they can't crawl over HTTPS.

The impact is immediate: zero traffic, zero conversions, and a support queue full of confused users. For e-commerce, SaaS, and any site handling sensitive data, even a 30-minute outage from an expired certificate is serious.

Method 1: Check SSL expiry with an online tool

The fastest way to check any domain's certificate: use InfiniUm's SSL Checker. Enter the domain name and it returns the expiry date, days remaining, issuer, certificate chain, and whether the cert is trusted by major browsers — all in under 3 seconds.

Method 2: Check via command line (OpenSSL)

For developers and sysadmins, the most reliable method is OpenSSL. This works on any Linux/macOS system:

# Check expiry date for any domain
echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null \
  | openssl x509 -noout -dates

# Output:
# notBefore=Jan 15 00:00:00 2026 GMT
# notAfter=Apr 15 23:59:59 2026 GMT

To check how many days remain:

# Returns number of days until expiry (negative = already expired)
echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null \
  | openssl x509 -noout -enddate \
  | sed 's/notAfter=//' \
  | xargs -I{} sh -c 'echo $(( ( $(date -d "{}" +%s) - $(date +%s) ) / 86400 )) days remaining'

Checking a local certificate file

# Check a .crt or .pem file directly
openssl x509 -in /path/to/certificate.crt -noout -dates

# Check with full details
openssl x509 -in /path/to/certificate.crt -text -noout | grep -A2 "Validity"

Method 3: Check via browser

Click the padlock icon in the browser address bar → Connection is secure → Certificate is valid. This shows the cert's expiry date and issuer. Useful for a quick check but impractical for monitoring multiple domains.

What to look for beyond the expiry date

Expiry is the most urgent thing to check, but a complete SSL health check includes:

• Certificate chain: the full chain from your cert to the root CA must be correctly installed. A missing intermediate cert causes some browsers to reject the connection even if the cert itself is valid.
• Domain coverage: the cert must cover the exact domain being accessed. A cert for example.com won't cover www.example.com unless it's a wildcard (*.example.com) or includes both as SANs (Subject Alternative Names).
• Issuer trust: the certificate must be issued by a CA trusted by major browsers. Self-signed certificates are never trusted by browsers outside of development environments.
• Key strength: RSA keys should be at least 2048-bit; ECDSA 256-bit is equivalent and faster. Weak keys are flagged by security scanners.

Let's Encrypt: auto-renewal and why it sometimes fails

Let's Encrypt certificates are free and valid for 90 days. The Certbot client sets up automated renewal via a cron job or systemd timer. In theory, renewal is fully automatic. In practice, several things can break it:

• Port 80 blocked: Let's Encrypt's HTTP-01 challenge requires port 80 to be accessible. If a firewall rule blocks port 80 after you finish setup, renewal fails silently.
• Nginx/Apache config changes: if you change your server config in a way that breaks Certbot's webroot or standalone validation method, renewal fails.
• DNS changes: if you use DNS-01 validation and your API credentials change (e.g. Cloudflare API token rotated), renewal fails.
• Cron job not running: if the system's cron daemon stops working or the renewal cron is accidentally deleted.

Check Let's Encrypt renewal status

# Test renewal without actually renewing
sudo certbot renew --dry-run

# Check renewal timer status (systemd)
systemctl status certbot.timer

# Check renewal logs
sudo cat /var/log/letsencrypt/letsencrypt.log | tail -50

Setting up SSL expiry monitoring

Don't rely on manual checks. Set up automated monitoring so you're alerted when a certificate has less than 30 days remaining.

Simple bash script for cron monitoring

#!/bin/bash
# ssl-check.sh — add to cron to run weekly
DOMAIN="yourdomain.com"
THRESHOLD=30
ALERT_EMAIL="you@yourdomain.com"

EXPIRY=$(echo | openssl s_client -connect $DOMAIN:443 -servername $DOMAIN 2>/dev/null \
  | openssl x509 -noout -enddate | sed 's/notAfter=//')

DAYS=$(( ( $(date -d "$EXPIRY" +%s) - $(date +%s) ) / 86400 ))

if [ $DAYS -lt $THRESHOLD ]; then
  echo "SSL certificate for $DOMAIN expires in $DAYS days ($EXPIRY)" \
    | mail -s "⚠️ SSL expiry warning: $DOMAIN" $ALERT_EMAIL
fi

# Add to cron — run weekly on Monday at 9am
0 9 * * 1 /opt/scripts/ssl-check.sh

Commercial certificates: renewal timeline

Commercial certificates (DigiCert, Sectigo, etc.) have longer validity periods — typically 1 year. Unlike Let's Encrypt, they don't auto-renew. Set calendar reminders:

• 90 days before expiry: start the renewal process (ordering, domain validation, installation)
• 30 days before expiry: if not renewed, escalate immediately
• 7 days before expiry: emergency escalation — contact your CA's support

Note: as of 2026, maximum certificate validity is 1 year (398 days). Multi-year certificates were discontinued. Some CAs sell multi-year plans but issue annual certs that require re-validation.

What to do when a certificate has already expired

1. For Let's Encrypt: run sudo certbot renew --force-renewal. If it fails, check the error output and resolve the validation issue.
2. For commercial certificates: contact your CA immediately — most have emergency re-issuance processes. Have your domain validation method ready.
3. Temporary workaround: if renewal will take more than a few hours, you can issue a free Let's Encrypt cert as a stop-gap for the same domain to restore availability.
4. After resolution: check why monitoring didn't catch it and fix the monitoring process.