How to test a TLS certificate using OpenSSL

A TLS endpoint can accept connections on the right port while serving the wrong virtual-host certificate, an incomplete chain, or a certificate that the client trust store rejects. Testing with OpenSSL checks the certificate from the client side, using the same service name that browsers, API clients, mail clients, or monitoring probes send during the handshake.

The openssl s_client command opens a TLS client session to a host and port. Explicit -servername keeps shared-address tests on the intended virtual host, while -verify_hostname checks that the served certificate covers the requested DNS name. The -verify_return_error option makes trust or name errors abort the check, and -brief -no-interactive keeps the output short before returning control to the shell.

The examples below use www.example.test on port 8443 with root-ca.pem as a private trust anchor. Replace the connection target and host name with the service being tested. Omit -CAfile when the endpoint chains to the system trust store, and add the correct -starttls protocol option only for services such as SMTP or IMAP that upgrade from clear text before presenting a certificate.

1. Identify the endpoint socket, TLS service name, and trust source for the check.

   Use the DNS name clients request as both -servername and -verify_hostname. The -connect target may be the same DNS name, an IP address, or a load balancer name, but the hostname verification value should remain the service name clients expect.

2. Run openssl s_client with SNI, hostname verification, and hard verification errors.

   $ openssl s_client -connect www.example.test:8443 -servername www.example.test -verify_hostname www.example.test -verify_return_error -CAfile root-ca.pem -brief -no-interactive
   Connecting to 127.0.0.1
   CONNECTION ESTABLISHED
   Protocol version: TLSv1.3
   Ciphersuite: TLS_AES_256_GCM_SHA384
   Peer certificate: O=Example Operations, CN=www.example.test
   Hash used: SHA256
   Signature type: rsa_pss_rsae_sha256
   Verification: OK
   Verified peername: www.example.test
   Negotiated TLS1.3 group: X25519MLKEM768

   Verification: OK means the served certificate chain built to the trust source used by this command. Verified peername means the requested host name matched the certificate identity.

3. Remove -CAfile when testing a publicly trusted endpoint with the operating system trust store.

   $ openssl s_client -connect www.example.com:443 -servername www.example.com -verify_hostname www.example.com -verify_return_error -brief -no-interactive

   Add -CAfile, -CApath, or -CAstore only when the endpoint depends on a private CA, lab root, or custom trust bundle that is not already trusted by the client running the check.

4. Treat hostname mismatch output as a failed certificate test.

   $ openssl s_client -connect www.example.test:8443 -servername www.example.test -verify_hostname api.example.test -verify_return_error -CAfile root-ca.pem -brief -no-interactive
   Connecting to 127.0.0.1
   depth=0 O=Example Operations, CN=www.example.test
   verify error:num=62:hostname mismatch
   ##### snipped #####

   Do not approve the endpoint from CONNECTION ESTABLISHED alone. A completed handshake can still serve a certificate that is expired, untrusted, incomplete, or valid for a different name.

5. Repeat the same command from the network path that matters to the affected client.

   A load balancer, CDN edge, split DNS answer, mail gateway, proxy, or direct IP test can present a different certificate from the one observed on an administrator workstation.