Testing SSL Configuration

Your SSL certificate is installed. The padlock appears. But is your server actually secure?

The certificate is just one piece. Protocol versions, cipher suites, certificate chains, security headers—any of these misconfigured can create vulnerabilities your users will discover before you do. Testing finds these problems first.

SSL Labs: The Industry Standard

SSL Labs (ssllabs.com/ssltest) is a confession booth for your server. Enter your domain, wait two minutes, and it will find what you missed, explain why it matters, and tell you exactly how to fix it.

What it examines:

• Certificate validity and complete chain
• Protocol versions (are TLS 1.0/1.1 still enabled?)
• Cipher suite strength and order
• Known vulnerabilities (POODLE, BEAST, Heartbleed)
• HSTS configuration
• Overall implementation quality

The grades:

• A+: Best-in-class security with HSTS preload
• A: Strong security, well configured
• B or lower: Problems need attention
• T: Certificate trust issues
• F: Serious vulnerabilities

Focus first on anything marked red or orange. SSL Labs explains each finding—what's wrong, why it matters, how to fix it. Run it after every configuration change.

OpenSSL: Command-Line Precision

When you need to test something specific, OpenSSL's s_client gives you direct control.

Basic connection test:

openssl s_client -connect example.com:443 -servername example.com

This performs a complete handshake and shows everything: protocol version negotiated, cipher suite selected, certificate chain received.

Test specific TLS versions:

openssl s_client -connect example.com:443 -tls1_2
openssl s_client -connect example.com:443 -tls1_3

Both should succeed. Testing -tls1 or -tls1_1 should fail on a properly configured server.

View the full certificate:

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

Shows validity dates, Subject Alternative Names, issuer—everything in the certificate.

Check the certificate chain:

openssl s_client -connect example.com:443 -showcerts

Count the certificate blocks. You should see your certificate plus intermediates. Missing intermediates cause errors in some browsers but not others—a maddening debugging experience.

Verify OCSP stapling:

openssl s_client -connect example.com:443 -servername example.com -status

Look for "OCSP Response Status: successful" and "Cert Status: good."

Browser Testing

Different browsers have different TLS implementations, different trust stores, different opinions about what's acceptable.

Test in all major browsers:

• Chrome/Edge (Chromium-based): Strict security requirements
• Firefox: Maintains its own trust store, independent policies
• Safari: Apple-specific requirements, especially on iOS
• Mobile browsers: Test on actual devices—mobile TLS capabilities sometimes differ

If your site works in Chrome but fails in Firefox, you likely have an incomplete certificate chain. If it works on desktop but fails on mobile, check your cipher suite order.

Browser DevTools:

• Security panel (Chrome/Edge F12): Shows connection details and warnings
• Certificate viewer (click padlock): Verify domains and validity
• Console: Mixed content warnings appear here
• Network tab: See actual protocol and cipher negotiated

Testing Security Headers

The certificate secures the connection. Headers tell browsers how to use it.

HSTS (HTTP Strict Transport Security):

curl -I https://example.com | grep -i strict-transport-security

Should return: Strict-Transport-Security: max-age=31536000; includeSubDomains

This tells browsers to always use HTTPS, even if someone types http://. Without it, the first request to your site is vulnerable.

Other headers worth checking:

curl -I https://example.com | grep -iE '(content-security|x-frame|x-content-type)'

Testing from Different Locations

Here's something uncomfortable: some networks actively interfere with TLS. Corporate proxies, national firewalls, certain ISPs—they can intercept, downgrade, or block encrypted connections. You won't know this affects your users unless you test from where they are.

Geographic testing:

• Use VPNs or proxy services to test from different countries
• Services like KeyCDN's Performance Test check from multiple global locations
• Test from corporate networks, home ISPs, and mobile networks

If your CDN serves different certificates in different regions, geographic testing catches misconfigurations that local testing misses.

Finding Mixed Content

One HTTP image on an HTTPS page breaks the padlock. The connection is encrypted, but users see a warning—and they should, because that unencrypted request leaks information.

Find mixed content:

• Browser console shows warnings for each HTTP resource
• Crawl your site with tools like "Why No Padlock"
• Review templates and third-party integrations—they're common culprits

Automated Monitoring

Manual testing catches problems once. Automated testing catches them continuously.

What to automate:

• Certificate expiration (alert at 30 days, panic at 7)
• SSL Labs grade changes
• Protocol or cipher suite changes
• HSTS header presence

How to automate:

• SSL Labs has an API for programmatic testing
• Monitoring services (Uptime Robot, Pingdom) check certificates
• Custom scripts with OpenSSL run via cron
• CI/CD integration tests staging before production

Expired certificates cause outages. Automated monitoring means you know before your users do.

Common Problems Testing Reveals

Old protocols still enabled: TLS 1.0/1.1 alongside TLS 1.2/1.3. Disable them.

Weak ciphers: RC4, 3DES, export ciphers. Remove them.

No forward secrecy: Only RSA key exchange. Enable ECDHE ciphers.

Incomplete chain: Missing intermediates. Add the full chain to your server config.

No HSTS: The header is missing. Add Strict-Transport-Security to your responses.

The Testing Checklist

After any SSL/TLS configuration change:

• SSL Labs grade is A or A+
• Certificate valid and not expiring within 30 days
• Certificate covers all served domains
• Complete certificate chain sent
• TLS 1.2 and 1.3 work; older versions rejected
• ECDHE cipher suites preferred
• HSTS header present with appropriate max-age
• Works in Chrome, Firefox, Safari, and mobile
• No mixed content warnings
• OCSP stapling working
• Automated monitoring in place