SSL certificate problems are one of the most disruptive technical issues a site can have. An expired certificate locks out every visitor with a browser warning. A misconfigured certificate causes silent failures. A certificate issued to the wrong domain breaks subdomains. And unlike most problems, certificate issues happen on a schedule — they expire — so they're entirely preventable if you know where to look.

Here's how to check any SSL certificate, what each field means, and what to do when something is wrong.

The Quick Check: Your Browser

For any site you're visiting, the fastest SSL check is right in your browser.

Chrome / Edge: Click the lock icon (or the "Connection is secure" text) next to the URL → Certificate is valid → Certificate details

Firefox: Click the lock icon → Connection Secure → More Information → View Certificate

This shows you:

  • Who the certificate was issued to (the domain)
  • Who issued it (the Certificate Authority)
  • Valid from / Valid to dates
  • The certificate's serial number and fingerprint

For a quick sanity check — is this certificate valid, and does it belong to the right domain — the browser UI is all you need.

The Thorough Check: Online Tool

For a complete analysis of a certificate including cipher suites, chain validity, HSTS configuration, and known vulnerabilities, use the SSL Checker tool. Enter any domain and it runs a full analysis without needing to install anything.

This is especially useful for:

  • Certificates on servers you can't access directly
  • Verifying a new certificate after installation
  • Checking certificates before they're about to expire
  • Auditing cipher suite strength (TLS 1.0/1.1 should be disabled)

The Command Line: openssl

For developers and sysadmins, openssl gives you direct certificate inspection from the terminal.

Check a remote server's certificate:

Command 
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -text

This returns the full certificate details. Key fields to look at:

Expiry date:

Command 
openssl s_client -connect example.com:443 -servername example.name </dev/null 2>/dev/null | openssl x509 -noout -dates

Output:

Command 
notBefore=Jan  1 00:00:00 2025 GMT
notAfter=Jan  1 00:00:00 2026 GMT

Check a local certificate file:

Command 
openssl x509 -in certificate.crt -noout -text
openssl x509 -in certificate.crt -noout -dates
openssl x509 -in certificate.crt -noout -subject -issuer

Verify a certificate chain:

Command 
openssl verify -CAfile chain.pem certificate.crt

Check days until expiry (scriptable):

Command 
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{} expr \( {} - $(date +%s) \) / 86400

Returns the number of days remaining. Useful in monitoring scripts.

What Each Certificate Field Means

Subject / Common Name (CN): The domain the certificate was issued for. Must match the domain you're visiting, or the browser will show a warning. For wildcard certificates, this is *.example.com.

Subject Alternative Names (SANs): The list of all domains the certificate covers. Modern certificates use SANs rather than just CN. A certificate might cover example.com, www.example.com, and api.example.com — all listed here. This is what the browser actually checks.

Issuer: The Certificate Authority (CA) that signed the certificate. Common ones: Let's Encrypt, DigiCert, Sectigo, Google Trust Services, Amazon. The issuer's own certificate is signed by a root CA trusted by browsers.

Validity period: Not Before and Not After dates. Certificates expire — Let's Encrypt certificates expire every 90 days (with auto-renewal). Commercial certificates typically last 1 year.

Key algorithm and size: RSA 2048-bit is the minimum; 4096-bit or EC P-256 are stronger. EC (elliptic curve) certificates offer equivalent security with smaller key sizes, which marginally improves performance.

TLS version: Your server should support TLS 1.2 and TLS 1.3. TLS 1.0 and 1.1 are deprecated and should be disabled — modern browsers refuse connections on these.

Certificate transparency: Modern certificates are logged in public Certificate Transparency logs. This is mandatory for certificates trusted by Chrome. It lets anyone audit what certificates have been issued for a domain — useful for detecting unauthorised certificates.

Common SSL Problems and How to Fix Them

Expired certificate The most common issue. Your browser shows "Your connection is not private" with error NET::ERR_CERT_DATE_INVALID.

Fix: Renew the certificate. If you're using Let's Encrypt with Certbot, run certbot renew. If using a paid certificate, purchase a renewal through your CA and install it. Set up monitoring to alert you 30 days before expiry so this never happens in production.

Certificate domain mismatch The certificate was issued for example.com but you're visiting www.example.com (or vice versa), and the certificate doesn't include the other as a SAN.

Fix: Either get a certificate that covers both (most certificates should), or redirect one to the other consistently.

Incomplete certificate chain Your server is presenting your certificate but not the intermediate certificates that connect it to a trusted root CA. Browsers that have cached the intermediate can connect; others see an error.

Fix: Configure your web server to send the full chain. With Nginx, use ssl_certificate pointing to a file that includes both your certificate and the intermediate bundle. With Apache, use SSLCertificateChainFile.

Check for this issue specifically:

Command 
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -A 1 "Certificate chain"

You should see at least 2 certificates in the chain (your certificate + intermediate).

Self-signed certificate Browsers don't trust certificates that aren't signed by a recognised CA. Self-signed certificates are fine for internal development but will trigger warnings for any public-facing site.

Fix: Get a certificate from a trusted CA. Let's Encrypt is free and automated for public domains.

Weak cipher suite The server negotiates a TLS connection using outdated or weak algorithms (RC4, DES, export-grade ciphers, TLS 1.0/1.1).

Check with:

Command 
nmap --script ssl-enum-ciphers -p 443 example.com

Fix: Update your web server's SSL configuration to modern cipher suites only. Mozilla's SSL Configuration Generator generates ready-to-paste configs for Nginx, Apache, and others.

Certificate Monitoring

Manually checking certificates before they expire doesn't scale. Options for automated monitoring:

Certbot auto-renewal: If you're using Let's Encrypt, Certbot sets up a cron job or systemd timer that auto-renews certificates when they have less than 30 days remaining. Verify it's working: certbot renew --dry-run

Uptime monitoring services: Most uptime monitors (UptimeRobot, Freshping, Better Uptime) include certificate expiry alerts. Set a 30-day warning threshold.

Custom script in cron: A simple bash script using the openssl command above can check expiry and send an email alert.

Command 
#!/bin/bash
DOMAIN="example.com"
DAYS_LEFT=$(echo | openssl s_client -connect $DOMAIN:443 -servername $DOMAIN 2>/dev/null | openssl x509 -noout -enddate | cut -d= -f2 | xargs -I{} python3 -c "from datetime import datetime; print((datetime.strptime('{}', '%b %d %H:%M:%S %Y %Z') - datetime.utcnow()).days)")
if [ "$DAYS_LEFT" -lt 30 ]; then
    echo "Certificate for $DOMAIN expires in $DAYS_LEFT days" | mail -s "SSL Warning" admin@example.com
fi

The Bottom Line

Certificate issues are predictable and preventable. The main ones — expiry, domain mismatch, incomplete chain — all show up clearly in an SSL check.

Run a check on any domain with the SSL Checker tool. For production servers, set up expiry monitoring with at least a 30-day alert window. And if you're still on TLS 1.0 or 1.1, disable them — any modern server should be TLS 1.2+ only.