TLS Errors & SSL Certificate Diagnostics with openssl

Updated: 2025-11-17

TLS Errors & SSL Certificate Diagnostics with openssl

This technical guide explains how SSL/TLS certificates work under the hood and how to diagnose certificate issues. Learn certificate chain validation, troubleshoot configuration problems, identify security vulnerabilities, and implement best practices for certificate management.

For expiration monitoring and renewal workflows, see SSL Certificate Expiration Monitoring. For expired certificate emergencies, see Expired SSL Certificate.

Understanding the Certificate Chain

When a browser connects to your site, it validates a chain of trust:

Root CA (pre-installed in browser/OS)
    └── Intermediate CA (provided by certificate issuer)
        └── Your Certificate (installed on your server)

Common mistake: Installing only your certificate without the intermediate. Works in some browsers (they can fetch it), fails in others.

What Gets Validated

Every HTTPS connection validates:

Certificate not expired - notAfter date is in the future
Certificate not yet valid - notBefore date is in the past
Domain matches - CN or SAN includes the requested domain
Chain is complete - intermediate leads to trusted root
Certificate not revoked - checked via OCSP or CRL
Signature is valid - cryptographic integrity check

Beyond Expiration: Other SSL Issues to Monitor

Issue	Symptom	How to Detect
Missing intermediate	Works in Chrome, fails in curl	`openssl s_client -showcerts`
Wrong domain	Certificate error for subdomain	Check SAN entries
Weak cipher	Security warning in browser	SSL Labs test
Mixed content	Padlock warning	Browser dev tools
Certificate revoked	Complete failure	OCSP check

Method 1: Diagnose Certificate Chain Issues

The most common SSL problem isn't expiration—it's incomplete certificate chains.

Verify Complete Certificate Chain

# Check certificate chain completeness
echo | openssl s_client -showcerts -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -text

# Count certificates in chain (should be 2-3: your cert + intermediate + sometimes root)
echo | openssl s_client -showcerts -servername example.com -connect example.com:443 2>/dev/null | grep -c "BEGIN CERTIFICATE"

What to look for: You should see at least 2 certificates (your certificate + intermediate). If only 1 certificate appears, the intermediate is missing.

Test Certificate Chain Validation

# Test if certificate chain validates correctly
echo | openssl s_client -showcerts -servername example.com -connect example.com:443 2>&1 | grep -i "verify return code"

# Verify return code meanings:
# 0 = OK
# 19 = self-signed certificate
# 20 = unable to get local issuer certificate (missing intermediate)
# 21 = unable to verify the first certificate (chain issues)

Diagnose Missing Intermediate Certificate

# Check if intermediate certificate is missing
echo | openssl s_client -servername example.com -connect example.com:443 2>&1 | grep "verify error"

# Common error: "unable to get local issuer certificate"
# This means intermediate certificate is missing from server configuration

Method 2: Diagnose Certificate Domain Mismatch Issues

Certificates must match the domain being accessed.

Check Certificate Subject and SAN

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

# Check Subject Alternative Names (SAN)
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

# Verify domain is covered
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -text | grep -E "DNS:|CN="

Common issues:

Certificate issued for example.com but accessed via www.example.com (missing SAN)
Wildcard certificate *.example.com doesn't cover example.com (root domain)
Certificate doesn't include all subdomains needed

Method 3: Diagnose Certificate Revocation Issues

Certificates can be revoked before expiration.

Check Certificate Revocation Status

# Check OCSP (Online Certificate Status Protocol) status
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -ocsp_uri

# Get OCSP URL and check revocation status
OCSP_URL=$(echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -ocsp_uri)
openssl ocsp -issuer intermediate.crt -cert your-cert.crt -url "$OCSP_URL"

Revocation statuses:

good = Certificate is valid
revoked = Certificate was revoked (security issue)
unknown = OCSP server can't determine status

Method 4: Diagnose TLS Protocol and Cipher Issues

Beyond certificates, TLS configuration matters for security.

Check Supported TLS Versions

# Test TLS 1.2 support
openssl s_client -tls1_2 -connect example.com:443 -servername example.com < /dev/null

# Test TLS 1.3 support
openssl s_client -tls1_3 -connect example.com:443 -servername example.com < /dev/null

# Check which TLS versions are supported
nmap --script ssl-enum-ciphers -p 443 example.com

Security best practice: Disable TLS 1.0 and TLS 1.1, require TLS 1.2 minimum, prefer TLS 1.3.

Check Cipher Suite Security

# List supported cipher suites
openssl s_client -connect example.com:443 -servername example.com < /dev/null | grep "Cipher"

# Test for weak ciphers
nmap --script ssl-enum-ciphers -p 443 example.com | grep -i "weak\|vulnerable"

Security issues to avoid:

RC4 ciphers (deprecated, insecure)
DES/3DES ciphers (weak encryption)
MD5/SHA1 signatures (weak hashing)

Method 5: Automated SSL Certificate Diagnostics with Zuzia.app

Checking by hand tells you the state right now. Zuzia checks from outside, around the clock, with nothing installed on the server.

How it works in Zuzia

Add a URL, a TCP port or a DNS record with the value you expect. The first check runs within about 30 seconds.
Websites can be checked as often as once a minute, from agents in Poland, New York and Singapore. Zuzia records the HTTP status code and response time of every check.
Zuzia warns you 14, 7 and 3 days before an SSL certificate expires, and does the same for the domain registration.
Alerts go by email, Slack, Discord, push (through your Pushover account) or SMS (through your Vonage account). A public status page or an embeddable widget shows your client the same uptime you see.

Setting it up

In the Zuzia dashboard, add the URL, port or DNS record.
Choose the check interval and your notification channels.
Optionally create a status page or a widget for the client.

For the checks in this guide that run on the server itself, install the Zuzia agent and save those commands as a scheduled task.

Method 6: Advanced SSL/TLS Diagnostic Techniques

Diagnose Mixed Content Issues

Mixed content (HTTP resources on HTTPS pages) breaks security:

# Check for mixed content in page
curl -s https://example.com | grep -E "http://" | grep -v "https://"

# Use browser dev tools (F12) to identify mixed content warnings

Fix: Update all HTTP URLs to HTTPS or use protocol-relative URLs.

Diagnose HSTS (HTTP Strict Transport Security) Issues

HSTS forces browsers to use HTTPS:

# Check HSTS header
curl -I https://example.com 2>&1 | grep -i "strict-transport-security"

# Verify HSTS is configured correctly
# Should include: max-age, includeSubDomains (optional), preload (optional)

Diagnose Certificate Transparency Issues

Certificate Transparency logs track all certificates:

# Check certificate transparency logs
# Use online tools like crt.sh or certificate-transparency.org
# Search for your domain to see all certificates issued

Use case: Detect unauthorized certificates issued for your domain.

Real-World SSL/TLS Diagnostic Scenarios

Scenario 1: Certificate Works in Chrome but Fails in curl

Symptom: Website loads fine in Chrome but curl fails with certificate errors.

Diagnosis:

# Check certificate chain
echo | openssl s_client -showcerts -servername example.com -connect example.com:443 2>&1 | grep "verify return code"

# If you see "unable to get local issuer certificate", intermediate is missing

Root cause: Missing intermediate certificate. Chrome can fetch it automatically, but curl cannot.

Solution: Install intermediate certificate on server. Most CAs provide intermediate certificates—download and configure your web server to serve the complete chain.

Scenario 2: Certificate Error for Subdomain

Symptom: Main domain works, but subdomain shows certificate error.

Diagnosis:

# Check SAN entries
echo | openssl s_client -servername subdomain.example.com -connect subdomain.example.com:443 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

Root cause: Certificate doesn't include subdomain in SAN (Subject Alternative Names).

Solution: Renew certificate with subdomain included in SAN, or use wildcard certificate *.example.com.

Scenario 3: Security Warning for Weak Cipher

Symptom: Browser shows security warning or SSL Labs gives low security rating.

Diagnosis:

# Check supported cipher suites
nmap --script ssl-enum-ciphers -p 443 example.com | grep -i "weak\|vulnerable"

# Check TLS version support
openssl s_client -connect example.com:443 -servername example.com < /dev/null | grep "Protocol"

Root cause: Server supports weak ciphers (RC4, DES) or old TLS versions (1.0, 1.1).

Solution: Update web server configuration to disable weak ciphers and require TLS 1.2 minimum.

Scenario 4: Certificate Chain Validation Fails

Symptom: Some clients can't validate certificate, others can.

Diagnosis:

# Test certificate chain from different locations
# Some clients have intermediate certificates cached, others don't

# Verify intermediate certificate is served
echo | openssl s_client -showcerts -servername example.com -connect example.com:443 2>/dev/null | grep -c "BEGIN CERTIFICATE"

Root cause: Incomplete certificate chain—server only sends end-entity certificate, not intermediate.

Solution: Configure web server to send complete chain (end-entity + intermediate certificates).

Common Mistakes to Avoid

Mistake 1: Setting Alert Thresholds Too Late

Problem: Setting alerts only when certificates expire in less than 7 days doesn't give enough time for renewal, especially for certificates that require manual renewal or approval processes.

Solution: Set alert thresholds well in advance - warning at 30 days, critical at 14 days, and emergency at 7 days. This provides adequate time for certificate renewal, especially for certificates requiring manual processes or approval.

Mistake 2: Monitoring Only Main Domains

Problem: Only monitoring the main website domain misses subdomains, API endpoints, and CDN domains that also have SSL certificates.

Solution: Monitor SSL certificates for all domains, including subdomains, API endpoints, CDN domains, and third-party service domains. Use Zuzia.app to add all domains and ensure comprehensive certificate coverage.

Mistake 3: Not Verifying Certificate Renewals

Problem: Assuming certificate renewals completed successfully without verification can lead to expired certificates if renewal processes fail silently.

Solution: After certificate renewal, verify the new certificate is active and update monitoring to track the new certificate. Use Zuzia.app's historical data to confirm certificate changes and ensure renewals completed successfully.

Mistake 4: Ignoring Certificate Chain Issues

Problem: Only checking certificate expiration dates without verifying certificate chains can miss intermediate certificate issues that cause SSL errors.

Solution: Monitor complete certificate chains, not just expiration dates. Use commands like openssl s_client -showcerts to verify certificate chains and ensure all intermediate certificates are valid.

Mistake 5: Relying Only on Manual Checks

Problem: Manually checking certificates occasionally misses expiration issues that occur between checks, especially for certificates with short validity periods.

Solution: Use automated monitoring like Zuzia.app that checks certificates continuously and alerts you proactively. Automated monitoring ensures you don't miss certificate issues and provides historical tracking of certificate changes.

Best Practices for SSL Certificate Monitoring

1. Monitor Certificates Regularly

Check SSL certificates at least daily. Certificates can expire unexpectedly, and daily checks ensure timely awareness. Use Zuzia.app automated monitoring to check certificates continuously.

2. Set Appropriate Alert Thresholds

Set different alert thresholds:

Warning: Certificate expires in < 30 days
Critical: Certificate expires in < 14 days
Emergency: Certificate expires in < 7 days

3. Monitor All Domains

Monitor SSL certificates for all domains, including:

Main website domains
API domains
Subdomains
CDN domains
Third-party service domains

4. Track Certificate Changes

Use Zuzia.app's historical data to track certificate changes over time. Understanding when certificates are renewed helps verify renewal processes are working.

5. Plan Certificate Renewals

Plan certificate renewals well in advance. Set up automated renewal processes where possible, and use monitoring to verify renewals complete successfully.

Troubleshooting Common SSL Certificate Issues

Certificate Expired

If a certificate has expired:

Check expiration date: echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate
Renew certificate immediately
Verify renewal: Check new expiration date
Update monitoring: Ensure new certificate is tracked

Certificate Expiring Soon

If a certificate is expiring soon:

Check days until expiration
Plan renewal: Schedule renewal before expiration
Set up alerts: Ensure monitoring alerts are configured
Verify renewal process: Test certificate renewal process

Certificate Chain Issues

If certificate chain issues occur:

Check certificate chain: openssl s_client -showcerts -connect example.com:443
Verify intermediate certificates
Update certificate chain if needed
Test certificate chain validity

Related guides, recipes, and problems

Related guides

FAQ: Common Questions About Monitoring SSL Certificates

How often are SSL certificates checked?

By default, SSL certificates are checked daily in Zuzia.app. You can change the frequency in check settings. For critical domains, consider checking more frequently to ensure timely awareness of expiration.

Does SSL monitoring work with wildcard certificates?

Yes, Zuzia.app checks all types of SSL certificates, including wildcard and multi-domain certificates. The system validates both SAN (Subject Alternative Names) and certificate chains, ensuring comprehensive certificate monitoring.

What happens if a certificate expires?

You'll receive notifications before expiration (default 14 days in advance). Zuzia.app will continue monitoring and notify you when the certificate is renewed. If expiration occurs, you'll receive immediate alerts to take action.

Can I monitor multiple domains?

Yes, you can add multiple URLs in Zuzia.app and all will be monitored simultaneously. Each domain has its own alert thresholds, allowing you to customize monitoring per domain based on importance and requirements.

How can I see certificate expiration trends over time?

Zuzia.app stores all SSL certificate data historically in its database, allowing you to view certificate expiration trends over time. You can see historical data showing certificate expiration dates on different dates, track certificate renewals, and identify patterns in certificate management.

What's the difference between SSL and TLS certificates?

SSL (Secure Sockets Layer) is the older protocol, while TLS (Transport Layer Security) is the modern replacement. Both use certificates, and the term "SSL certificate" is commonly used to refer to both SSL and TLS certificates. Modern systems use TLS, but certificates are often still called "SSL certificates."

Does Zuzia.app use AI to analyze SSL certificate patterns?

On paid plans, AI can read the output of your scheduled tasks and commands, explain it in plain language and alert you only when it spots a problem. Metric alerts work without AI: Zuzia alerts when CPU, RAM or load drifts from the server's normal and forecasts when a disk will fill up.

What should I do if my SSL certificate expires?

If your SSL certificate expires, immediately renew it through your certificate authority or hosting provider. After renewal, verify the new certificate is active using openssl s_client command, update your monitoring to track the new certificate, and ensure all domains using the certificate are updated. For detailed troubleshooting, see Expired SSL Certificate for comprehensive solutions.

How can I prevent SSL certificate expiration issues?

Prevent SSL certificate expiration by setting up automated certificate renewal where possible, monitoring certificates continuously with Zuzia.app, setting alert thresholds well in advance (30 days before expiration), maintaining a certificate renewal calendar, and using automated renewal tools like Let's Encrypt with certbot for automatic renewals.

Can I monitor SSL certificates for internal servers?

Yes, you can monitor SSL certificates for internal servers if they're accessible from your monitoring location. However, internal servers behind firewalls may require VPN access or agent-based monitoring. Zuzia.app can monitor any SSL certificate that's accessible via HTTPS, including internal domains if network access is configured correctly.