SSL Certificate Problems

SSL Certificate Problems

SSL/TLS certificate errors are highly disruptive: browsers show scary warning pages, APIs fail with cryptic SSL errors, and applications that verify certificates refuse to connect. Most certificate problems fall into three categories: expired certificates, hostname mismatches (the certificate does not match the domain), or incomplete certificate chains (intermediate certificate missing). Each has a clear diagnostic and fix.

Common SSL errors

Diagnosing SSL issues

# Check a live server's certificate from the command line:
openssl s_client -connect example.com:443 -servername example.com /dev/null

openssl s_client output key sections

depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = example.com
verify return:1
---
Certificate chain
 0 s:CN = example.com
   i:C = US, O = Let's Encrypt, CN = R3    ← Issued by R3 (Let's Encrypt)
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = ISRG Root X1              ← Intermediate cert present
---
Verify return code: 0 (ok)     ← 0 = no errors

# Check expiry date:
openssl s_client -connect example.com:443 -servername example.com /dev/null |   openssl x509 -noout -dates

Certificate dates output

notBefore=Jun  1 00:00:00 2025 GMT
notAfter=Aug 30 23:59:59 2025 GMT
# Expires in about 83 days — OK. Certbot should renew before 30-day threshold

# Check what domain names (SANs) the certificate covers:
openssl s_client -connect example.com:443 -servername example.com /dev/null |   openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

Handling expired certificates

# Certbot renewal (Let's Encrypt):
sudo certbot renew --force-renewal    # Force renewal even if not expiring soon
sudo certbot renew --dry-run          # Test renewal without making changes

# Check certbot auto-renewal timer:
systemctl status certbot.timer
sudo journalctl -u certbot.service --since "7 days ago"

# If certbot fails — common reasons:
# Port 80/443 blocked by firewall during ACME challenge:
sudo ufw allow 80/tcp    # Let's Encrypt needs port 80 for HTTP challenge
sudo certbot renew

# If renewal succeeds but nginx still serves old cert:
sudo systemctl reload nginx    # Reload nginx to pick up new cert files

Certificate chain issues

# Symptom: certificate works in browser but fails in curl or Python requests
# Cause: incomplete certificate chain (missing intermediate certificate)

# Verify chain completeness:
openssl s_client -connect example.com:443 -servername example.com /dev/null |   grep "Certificate chain"
# Should show depth 0 (your cert) AND depth 1 (intermediate)
# If only depth 0 shows: missing intermediate cert

# Fix for nginx: use fullchain.pem, not cert.pem:
sudo nano /etc/nginx/sites-available/example.com

Correct nginx SSL configuration

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;    # Full chain
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# fullchain.pem = your cert + intermediate cert(s) bundled together
# cert.pem = your cert only (incomplete chain)

# Fix for Apache:
# SSLCertificateFile    /etc/letsencrypt/live/example.com/cert.pem
# SSLCertificateChainFile /etc/letsencrypt/live/example.com/chain.pem
# OR (preferred):
# SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem

sudo nginx -t && sudo systemctl reload nginx    # Reload after fixing

Conclusion

Always use fullchain.pem (not cert.pem) in nginx and Apache TLS configurations to include the intermediate certificate chain. Without the intermediates, some clients (particularly older Android devices and curl on older systems) will reject the certificate even though browsers accept it (because browsers cache intermediate certificates). Test certificate validity from the command line with openssl s_client and from an external perspective with curl -v https://yourdomain.com to catch chain issues before they affect users.