How to Compare Two Certificates for Troubleshooting TLS/SSL Connection Issues

Troubleshooting TLS/SSL connection issues often involves comparing certificates between a working and non-working environment. This article outlines key areas and techniques to effectively compare two certificates and pinpoint potential problems.

Comparing Certificate Details Using OpenSSL

The provided examples use OpenSSL’s s_client command, a powerful tool for analyzing SSL/TLS connections. Let’s break down how to interpret the output and compare certificates:

Initial Connection and Handshake:

SSL_connect:SSLv3 write client hello A: This line indicates the client is initiating a connection using SSLv3 or TLSv1. Note that the production server accepts SSLv2/v3, while the staging server only accepts SSLv3, which might indicate a compatibility issue with older protocols. Modern best practice is to disable SSLv2 and SSLv3 due to known vulnerabilities.
depth=...: This shows the certificate chain. Compare the depth values and the C = ..., O = ..., CN = ... fields (Certificate Authority, Organization, Common Name) in both outputs to ensure the certificate authorities and issuer are consistent between environments. Any discrepancies here could signify a trust issue.
verify return:1: This indicates successful verification of each certificate in the chain. While both connections show successful verification, ensure the trusted root certificate authorities are the same on both the client device and the servers.

Cipher Suites:

Cipher is...: This reveals the negotiated cipher suite. The staging server uses ECDHE-RSA-AES128-GCM-SHA256, while the production server uses AES128-GCM-SHA256. While both are strong ciphers, the difference might point to a client-side cipher suite preference that the staging server doesn’t support or has prioritized differently.

Secure Renegotiation:

Secure Renegotiation IS...: This flag indicates whether secure renegotiation is supported. The difference between “supported” on the staging server and “NOT supported” on the production server is unlikely to be the root cause, but it’s worth investigating. Focus on ensuring consistent cipher suite support and TLS protocol versions first.

Session Details:

While the Session IDs and Master Keys will differ, compare the following:

Protocol : TLSv1.2: Both connections use TLSv1.2, ruling out a major protocol version mismatch.
TLS session ticket lifetime hint:: The staging server provides a session ticket hint, suggesting it’s attempting to resume a previous session. Check if the client is correctly handling session tickets.

Potential Causes and Further Investigation

Based on the comparison, the primary areas to investigate are:

TLS Protocol Support: Although both servers use TLSv1.2 in the successful connection, verify that the client device is explicitly configured to use TLSv1.2 and not falling back to older, insecure protocols when connecting to the staging server.
Cipher Suite Compatibility: Investigate the client device’s supported cipher suites. Ensure the staging server supports at least one cipher suite in common with the client and that it’s enabled in the server’s configuration.
Client-Side Configuration: Review the client device’s SSL/TLS configuration for any specific settings related to cipher suite order, protocol versions, or certificate validation. A mismatch in these settings between the production and staging environments could lead to connection failures.
Firewall or Network Issues: Rule out any firewall or network restrictions that might be blocking specific ports or protocols on the staging server.

By systematically comparing the certificates and related connection details, you can effectively diagnose and resolve TLS/SSL connection problems. Remember to consult official documentation for your specific client device and server software for detailed configuration guidance.