SSL/TLS Testing

TLS Fundamentals #

Transport Layer Security (TLS) is the protocol that puts the “S” in HTTPS. It provides encryption, authentication, and data integrity for network communications. For QA engineers, understanding TLS is essential because misconfigured certificates cause outages, security headers prevent attacks, and mixed content breaks page functionality.

TLS 1.2 vs TLS 1.3 #

TLS 1.2 has been the standard since 2008, but TLS 1.3 (2018) brought significant improvements:

The TLS 1.3 handshake is faster and simpler. The client sends its key share in the first message, allowing the server to derive the encryption key immediately. This reduces connection setup time — critical for performance testing.

The Handshake Process #

Every HTTPS connection begins with a TLS handshake:

1. ClientHello: Client sends supported TLS versions, cipher suites, and a random value
2. ServerHello: Server selects TLS version and cipher suite, sends its certificate
3. Certificate verification: Client validates the certificate chain against trusted CAs
4. Key exchange: Both sides generate shared secret keys
5. Finished: Encrypted communication begins

Certificate Chain #

A certificate chain establishes trust from the server to a recognized authority:

• Leaf certificate: Installed on the server, contains the domain name
• Intermediate certificate(s): Issued by the CA, bridges leaf to root
• Root certificate: Pre-installed in the OS/browser trust store

If any intermediate certificate is missing, some clients fail to validate the chain — a common bug that only appears on specific devices or browsers.

SSL/TLS Testing Checklist #

Certificate Validity #

• Certificate not expired (check notAfter date)
• Domain name matches certificate Subject or SAN fields
• Certificate chain is complete (no missing intermediates)
• Certificate is issued by a trusted CA (not self-signed in production)
• Certificate revocation status is clean (OCSP/CRL check)

Protocol Configuration #

• TLS 1.2 and 1.3 are enabled
• TLS 1.0 and 1.1 are disabled
• SSL 2.0 and 3.0 are disabled
• Strong cipher suites only (no RC4, 3DES, or export ciphers)
• Forward secrecy is enabled (ECDHE key exchange)

Security Headers #

• HSTS header present with appropriate max-age
• No mixed content (HTTP resources on HTTPS pages)
• Secure cookie attributes set (Secure, HttpOnly, SameSite)
• HTTP to HTTPS redirect configured

Mixed Content Detection #

Mixed content occurs when an HTTPS page loads resources over HTTP:

• Active mixed content (blocked): Scripts, stylesheets, iframes loaded over HTTP
• Passive mixed content (warning): Images, audio, video loaded over HTTP

SSL Testing Tools #

openssl s_client #

# Connect and show certificate details
openssl s_client -connect example.com:443 -servername example.com

# Check certificate expiration
openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

# Verify certificate chain
openssl s_client -connect example.com:443 -showcerts

# Test specific TLS version
openssl s_client -connect example.com:443 -tls1_2
openssl s_client -connect example.com:443 -tls1_3

Qualys SSL Labs #

The free online scanner at ssllabs.com/ssltest provides a comprehensive grade (A+ to F) and detailed analysis of TLS configuration, cipher suites, certificate chain, and known vulnerabilities.

testssl.sh #

# Comprehensive SSL/TLS audit
./testssl.sh example.com

# Check specific vulnerability
./testssl.sh --heartbleed example.com

Advanced TLS Testing #

Certificate Pinning (Mobile Apps) #

Certificate pinning embeds the expected certificate or public key in the mobile app, rejecting any other certificate — even valid ones. Testing requires:

• Verifying the app rejects connections with wrong certificates
• Testing pin rotation: when the certificate changes, does the app update gracefully?
• Checking network security config on Android (network_security_config.xml)

Mutual TLS (mTLS) #

In mTLS, both client and server present certificates. Common in microservice architectures and B2B APIs:

# Test with client certificate
openssl s_client -connect api.example.com:443 \
  -cert client.crt -key client.key

Test scenarios: Valid client cert, expired client cert, wrong CA, no client cert, revoked client cert.

Let’s Encrypt Auto-Renewal Testing #

If your application uses Let’s Encrypt certificates (90-day validity), test:

1. Renewal process works before expiration (certbot renew)
2. Certificate is reloaded without server restart
3. OCSP stapling continues after renewal
4. No downtime during certificate rotation

Hands-On Exercise #

Audit a website’s SSL configuration:

1. Run SSL Labs scan and document the grade
2. Use openssl to check certificate details, chain, and expiration
3. Identify any vulnerabilities (weak ciphers, missing intermediates)
4. Document findings with severity levels
5. Recommend specific fixes for each finding

# Certificate details
openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -text | head -30

# Check expiration
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

# Check supported protocols
for proto in tls1 tls1_1 tls1_2 tls1_3; do
  echo -n "$proto: "
  echo | openssl s_client -connect example.com:443 -$proto 2>/dev/null | grep "Protocol"
done

Pro Tips #

• Set up certificate expiration alerts — expired certs cause outages, not just warnings
• Test with TLS 1.0/1.1 disabled to ensure nothing breaks for clients that require them
• Verify certificate Subject Alternative Names (SANs) match all expected domains
• Check for HTTP to HTTPS redirect and HSTS header on every deployment
• Test from multiple clients (browser, mobile, API) — some may handle certs differently

Key Takeaways #

1. SSL/TLS configuration is a critical testing area — misconfigurations cause outages and security vulnerabilities
2. Certificate lifecycle management (expiration, renewal, chain completeness) needs continuous testing
3. Tools like SSL Labs provide an easy first pass; openssl provides detailed manual investigation
4. Mixed content testing is essential for any HTTPS migration or deployment