TLS — It went wrong, now what

S Poon
2 min readApr 17, 2020

--

Transport Layer Security (TLS) is amazing, when it works. When it is not working, it is painful to debug.

I will show you how to use OpenSSL as a testing tool.

If the communication is a one-way TLS, there is no need to provide the TLS client’s private and public key.

The command to use :

openssl s_client -connect <servername>:<port> -tls1_2 -servername <servername>

This will force the OpenSSL to use TLS 1.2, and with the Server Name Indication feature enabled.

Below is an example using cnn.com:

A successful handshake will put the terminal/session in a seemingly suspend state like the above.

However, if the TLS server is configured for mutual TLS, which means the server requires the client to send in the client’s credentials, the OpenSSL command must include additional parameters for the private key, public key and the issuer’s CA certificate(s). The following assumes the materials are all in pem format. If the key material is in a different format, you can add additional parameters to indicate what the format the file is in.

openssl s_client -connect <servername:port> -tls1_2 -servername <servername> -key <private_key> -cert <public_cert> -CAfile <ca-file>

Whether or not the one-way TLS or mutual TLS is used, the end result is the same, if the connection is successful, the terminal/session is in a suspend state.

If the connection terminates immediately, and you fall-back to the command prompt, the TLS communication is not established successfully. The below screenshot highlights this:

--

--