← Back to Blog

TLS/SSL · 16 min read · July 08, 2026

SSL/TLS Certificate Checker — How to Verify Your Cert Is Valid in 2026

An expired or misconfigured SSL/TLS certificate can take your entire site offline in minutes. Here is exactly how to check every aspect of your certificate's health — expiry, trust chain, domain matching, revocation, and configuration — using the tools you already have on your server.

What Makes an SSL/TLS Certificate "Valid"?

A certificate is valid only when all five of these conditions are met simultaneously:

1. The certificate has not expired. The current date falls between the notBefore and notAfter dates.
2. The certificate chain is complete and trusted. All intermediate certificates are present, and the chain terminates at a root CA trusted by the client.
3. The domain name matches. The certificate's Common Name (CN) or Subject Alternative Names (SANs) include the domain you are connecting to.
4. The certificate has not been revoked. The certificate is not listed in the CA's Certificate Revocation List (CRL) or OCSP responder.
5. The cipher suite and protocol are secure. The server supports modern TLS versions (1.2 or 1.3) and does not use weak ciphers.

Each of these can fail independently. You might have a perfectly valid-but-expired certificate, or a current certificate with a broken chain. Most monitoring tools only check expiry. That is not enough.

How to Check Certificate Expiry from the Command Line

OpenSSL is the Swiss Army knife of certificate inspection. It is installed by default on every major Linux distribution. Here is how to use it to check a remote server's certificate:

# Check certificate dates (notBefore and notAfter)
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

# Output:
# notBefore=Apr  1 00:00:00 2026 GMT
# notAfter=Jun 30 23:59:59 2026 GMT

The -servername flag is critical for servers that host multiple domains on the same IP (SNI). Without it, you will get the default certificate, which may be for a different domain.

To get the remaining validity in days, use a small script:

# Check days until expiry
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate | cut -d= -f2 | xargs -I {} date -d "{}" +%s | xargs -I {} sh -c 'echo "Expires in: $((({} - $(date +%s)) / 86400)) days"'

Verifying the Certificate Chain

A certificate chain is a sequence from your server's leaf certificate through one or more intermediate certificates to a trusted root CA. If any link in this chain is missing, browsers will show a warning.

# View the full certificate chain
echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null

This outputs every certificate in the chain, PEM-encoded. You should see at least three certificates: the leaf (your domain), one or more intermediates (issued by your CA), and optionally the root (though roots are typically sent only by the client).

Check for missing intermediate certificates

If your server does not send the full chain, some clients (especially mobile apps and IoT devices) will fail to validate your certificate. Test by simulating a client that only trusts known roots:

# Simulate a mobile client with limited root store
echo | openssl s_client -connect example.com:443 -servername example.com -CApath /etc/ssl/certs 2>&1 | grep "verify return"

# Expected: "verify return:1"
# If you see "verify error:num=20" or "num=21", the chain is incomplete

A return code of 1 means the chain is valid. Code 20 indicates the issuer cannot be located (missing intermediate). Code 21 means the chain is too long or the root is untrusted.

Checking Domain Name Matching

A certificate is only valid for the domain names listed in its Subject Alternative Names (SAN) extension. The Common Name (CN) field is now deprecated for name matching in all modern browsers.

# Extract Subject Alternative Names
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -ext subjectAltName

# Output:
# X509v3 Subject Alternative Name:
#     DNS:example.com, DNS:www.example.com, DNS:admin.example.com

If the domain you are connecting to does not appear in this list (as a DNS entry), the certificate will trigger a hostname mismatch warning. Wildcard certificates (*.example.com) cover all subdomains at one level but do not cover the bare domain (example.com) itself.

Checking Certificate Revocation Status

Even a current, trusted certificate can be revoked if the private key was compromised, the certificate was issued by mistake, or the domain ownership changed. There are two revocation checking mechanisms:

OCSP (Online Certificate Status Protocol)

# Check OCSP status for a remote certificate
echo | openssl s_client -connect example.com:443 -servername example.com -status 2>/dev/null | grep -A 20 "OCSP response"

# Look for: "OCSP Response Status: successful (0x0)"
# And: "Cert Status: good"

CRL (Certificate Revocation List)

# Find the CRL distribution point from the certificate
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text | grep -A 1 "CRL Distribution"

# Then download and check the CRL
# curl -o crl.der <CRL_URL>
# openssl crl -inform DER -in crl.der -text -noout | grep "Serial Number"

Checking TLS Protocol and Cipher Configuration

A certificate can be perfectly valid while the server's TLS configuration is dangerously outdated. Here is how to audit your cipher and protocol support:

# Check supported TLS versions (requires testssl.sh or nmap)
nmap --script ssl-enum-ciphers -p 443 example.com

# Or using openssl for a specific protocol version
echo | openssl s_client -connect example.com:443 -tls1_2 2>/dev/null | grep "Protocol"
echo | openssl s_client -connect example.com:443 -tls1_3 2>/dev/null | grep "Protocol"

Your server should support TLS 1.2 and TLS 1.3. TLS 1.0 and 1.1 are deprecated and should be disabled. Weak ciphers like RC4, 3DES, and CBC-mode ciphers should be removed. Modern servers should prioritise TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256 (TLS 1.3 ciphers).

Using testssl.sh for a comprehensive audit

The most thorough open-source TLS checker is testssl.sh. It tests 60+ TLS parameters including cipher strength, protocol support, certificate information, and known vulnerabilities:

# Download and run testssl.sh (no install required)
wget -q https://testssl.sh/testssl.sh
chmod +x testssl.sh
./testssl.sh --quiet --color 0 example.com:443 | head -80

This will generate a report covering Heartbleed, ROBOT, CRIME, BREACH, LOGJAM, FREAK, POODLE, and a dozen other named attacks. If your server scores below an A-, you have work to do.

Automated Certificate Monitoring — Why You Need It

Manual checks are useful for troubleshooting, but they do not scale. Here is why automated monitoring matters in 2026:

• 90-day validity means 4 renewal cycles per year. Miss one, and your site goes down. With auto-renewal from LetsEncrypt, Certbot handles the renewal, but the renewal itself can silently fail (port 80 blocked, DNS challenge expired, rate limit hit). You need to verify that the renewed certificate is actually deployed.
• Chain issues are invisible from the inside. Your server may serve a valid certificate chain, but CDNs, reverse proxies, and load balancers can strip or replace intermediate certificates. The only way to catch this is to check from the outside.
• Certificate revocation can happen at any time. If your private key is leaked (e.g., through a compromised CI/CD pipeline), your CA may revoke your certificate instantly. Without monitoring, you will not know until users start reporting errors.

Setting Up a Simple Cron-Based Certificate Checker

Here is a bash script you can run weekly via cron. Save it as /usr/local/bin/check-certs.sh and make it executable:

#!/bin/bash
# Check certificates for all domains and alert if any expires within 14 days
DOMAINS=("example.com" "www.example.com" "admin.example.com")
THRESHOLD=14
ALERT_EMAIL="[email protected]"

for domain in "${DOMAINS[@]}"; do
  expiry_epoch=$(echo | openssl s_client -connect "$domain:443" -servername "$domain" 2>/dev/null \
    | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2 \
    | xargs -I {} date -d "{}" +%s 2>/dev/null)

  if [ -z "$expiry_epoch" ]; then
    echo "WARNING: Could not retrieve certificate for $domain"
    continue
  fi

  now_epoch=$(date +%s)
  days_left=$(( (expiry_epoch - now_epoch) / 86400 ))

  if [ "$days_left" -lt "$THRESHOLD" ]; then
    echo "ALERT: Certificate for $domain expires in $days_left days!"
    # Send alert (mail or webhook)
    # mail -s "Cert Alert: $domain expires in $days_left days" "$ALERT_EMAIL"
  else
    echo "OK: $domain certificate valid for $days_left days"
  fi
done

Add a weekly cron entry:

# Check certificates every Monday at 6 AM
0 6 * * 1 /usr/local/bin/check-certs.sh

This is a bare-bones approach. A production-grade solution would also check chain completeness, revocation status, and cipher strength — ideally via an external service that sees what your users see.

Checking Certificates on Popular Platforms

Nginx

To verify which certificate Nginx is actually serving (useful when you have multiple configs):

# Find which certificate Nginx uses for a given server block
nginx -T 2>/dev/null | grep -A 5 "server_name yourdomain" | grep ssl_certificate

# Output:
# ssl_certificate /etc/letsencrypt/live/yourdomain/fullchain.pem;
# ssl_certificate_key /etc/letsencrypt/live/yourdomain/privkey.pem;

Apache

# Check which certificate Apache is using
apache2ctl -S 2>/dev/null | grep -A 5 "port 443"

# Or check the config directly
grep -r "SSLCertificateFile" /etc/apache2/sites-enabled/

Caddy

Caddy handles certificate management automatically, but you can inspect the cached certificates:

# Caddy stores certificates in its data directory
ls /var/lib/caddy/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/
# Each domain has its own directory with .crt and .key files

Common Certificate Problems and How to Fix Them

1. Certificate about to expire

Fix: Run your ACME client (Certbot, acme.sh, or Caddy built-in) to renew. If auto-renewal failed, check that port 80 is reachable (for HTTP challenges) or that DNS records are correct (for DNS challenges). If you hit LetsEncrypt rate limits (50 certificates per domain per week), you may need to wait.

2. Incomplete certificate chain

Fix: Ensure your server is configured to serve the fullchain.pem file (which includes intermediates), not just cert.pem (which is the leaf only). In Nginx: ssl_certificate /path/to/fullchain.pem;. For Caddy, this is handled automatically.

3. Domain mismatch

Fix: The certificate you are serving does not cover the domain name the client is using. Request a new certificate that includes all domain variants (with and without www, subdomains, etc.) in the SANs list. Wildcard certificates (*.example.com) cover all first-level subdomains.

4. Revoked certificate

Fix: Immediately revoke the old certificate (if not already done by the CA) and issue a new one. Investigate why the key was compromised — check your CI/CD logs, SSH access, and any third-party services that had access to the private key.

5. Weak cipher or outdated protocol

Fix: Update your TLS configuration to disable TLS 1.0/1.1, remove weak ciphers, and prioritise TLS 1.3. Use Mozilla's SSL Configuration Generator (ssl-config.mozilla.org) to generate a secure config for your web server.

The Bottom Line

SSL/TLS certificates are the foundation of encrypted web communication, but they are increasingly fragile. With 90-day validity, automated renewal that can silently fail, and a growing set of requirements for chain completeness and modern ciphers, manual checking is no longer viable for any production system.

The commands and scripts in this guide give you the tools to audit your certificates from the command line at any time. But the real solution for production environments is continuous automated monitoring — checking expiry, chain, revocation, and cipher configuration from an external perspective, notifying you the moment anything degrades.

Your users see certificate errors as a trust failure. Your domain authority suffers. Do not wait for an expiry alert at 3 AM on a Sunday. Set up monitoring now, while everything is working.