SSL Certificate Validation: Beyond the Padlock

openssl s_client is your go-to command-line tool for debugging SSL/TLS connections, and online checkers offer a quick, visual way to assess certificate health.

Here’s how to use openssl s_client to diagnose issues:

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

This command establishes a TLS connection to example.com on port 443. The -servername flag is crucial for SNI (Server Name Indication), allowing the server to present the correct certificate for example.com if it hosts multiple domains.

The output will show you the certificate chain presented by the server. Look for:

• Certificate issuer: Ensure it’s a trusted Certificate Authority (CA).
• Validity dates: Check notBefore and notAfter to confirm the certificate is currently valid.
• Subject Alternative Names (SANs): Verify that DNS:example.com (and any other required subdomains) is listed.

Common openssl s_client findings and fixes:

1. verify error:num=18:self signed certificate: The server is presenting a certificate signed by itself, not a trusted CA.

   • Diagnosis: The openssl s_client output will clearly state "self signed certificate" and the issuer will be the same as the subject.
   • Fix: Obtain a certificate from a trusted CA (e.g., Let’s Encrypt, DigiCert, Sectigo) and configure your web server to use it. For testing, you can bypass verification with openssl s_client -connect example.com:443 -servername example.com -CAfile /path/to/your/test/cert.pem, but this is never for production.
   • Why it works: Browsers and clients trust certificates issued by well-known CAs. Self-signed certificates are inherently untrusted and will cause security warnings.

2. verify error:num=10:certificate has expired: The certificate’s notAfter date has passed.

   • Diagnosis: The openssl s_client output will show a notAfter date in the past.
   • Fix: Renew your SSL certificate with your CA. This usually involves generating a new Certificate Signing Request (CSR) and going through the renewal process with your provider.
   • Why it works: Certificates have an expiration date for security reasons; they need to be re-validated periodically.

3. verify error:num=19:certificate is not yet valid: The certificate’s notBefore date is in the future.

   • Diagnosis: The openssl s_client output will show a notBefore date in the future.
   • Fix: Wait for the notBefore date to pass, or if this is an error in issuance, contact your CA to have it reissued with the correct dates.
   • Why it works: Certificates are not active until their specified start date.

4. verify error:num=11:unable to get local issuer certificate or verify error:num=20:unable to get certificate chain: The server is not sending the full certificate chain (intermediate certificates).

   • Diagnosis: The openssl s_client output will show the server’s certificate but not the intermediate(s) or root CA certificate.
   • Fix: Configure your web server to serve the full certificate chain. This typically involves concatenating your server certificate and any required intermediate certificates into a single file (often named fullchain.pem or similar).
   • Why it works: Clients need the intermediate certificates to "walk the chain" back to a root CA that they already trust. Without them, the client cannot verify the server’s certificate.

5. verify error:num=21:unable to verify the first certificate: Often related to the server’s certificate not matching the hostname or the server not trusting the CA that signed the certificate.

   • Diagnosis: Check the subject and subjectAltName fields in the openssl s_client output against the hostname you are connecting to. Also, check the issuer field.
   • Fix: Ensure the certificate’s Subject Alternative Names (SANs) include the exact hostname you are using (e.g., DNS:www.example.com, DNS:example.com). If the issue is trust, ensure your system’s root CA store is up-to-date and that the CA that issued the certificate is present.
   • Why it works: The TLS handshake requires the presented certificate’s identity (via SANs) to match the requested hostname. The client must also trust the issuing CA.

6. NO CERTIFICATE RETURNED: The server didn’t send any certificate at all.

   • Diagnosis: The openssl s_client output will be very short, with no certificate details printed.
   • Fix: Ensure your web server is correctly configured to load and present an SSL certificate for the given virtual host or domain. Check your server’s configuration files (e.g., Apache’s SSLCertificateFile, Nginx’s ssl_certificate).
   • Why it works: A web server needs a certificate configured to enable HTTPS. If it’s missing or misconfigured, it cannot establish a secure connection.

Online SSL Checkers:

Tools like SSL Labs’ SSL Test (https://www.ssllabs.com/ssltest/) provide a comprehensive, human-readable report. They check for:

• Certificate validity (expiration, trust chain).
• Protocol support (TLS versions).
• Cipher suites.
• Vulnerabilities.

These tools are excellent for a high-level overview and often pinpoint issues that openssl s_client might only hint at.

After fixing certificate chain issues, you might encounter errors related to cipher suite negotiation or protocol version mismatches.