Testing Secure Connections with OpenSSL

When you need to verify a connection to a server is secure, the OpenSSL toolkit can provide you with detailed information about the session and allow you to interact with the server.

If you're attempting to connect to a server using SocketTools, and it's failing with an "invalid security context" error, OpenSSL can also be used to confirm the connection is working independently of your application.

You will need to install OpenSSL on your development system to use the commands in this article. You can download an installation package that we provide or visit the OpenSSL website for more information on how to obtain other binaries for Windows.

» Download OpenSSL

Checking Web Servers

One of the most common situations is testing a website to ensure the connection is secure. Here is an example of what that command would look like:

openssl s_client -tls1_2 -connect test.sockettools.com:443

This tells the OpenSSL command to function as a client (the s_client option), the hostname and port number to connect to, and that it should only use TLS 1.2 to establish a connection.

It's advisable to use the -tls1_2 option because this is how SocketTools normally connects with a server, and by default will not use earlier versions of TLS.

Here's what some of the output from the command would look like:

The Protocol value will will tell you which version of TLS was used, and the Cipher value will tell you which cipher suite was selected. By default, the client and server will always negotiate for the most secure algorithms which are common to both systems.

If you encounter errors with the initial TLS handshake, you can add the options -showcerts and -tlsextdebug to the command, and that will display some additional debugging information. For example:

openssl s_client -tls1_2 -showcerts -tlsextdebug -connect test.sockettools.com:443

The -showcerts option will display additional information about the security certificates and the certificate chain. The -tlsextdebug option will show the TLS extensions which are supported by the server.

Checking FTP Servers

To check a secure connection to an FTP server, you will need to use some additional options because most FTP servers today use explicit TLS. This means that the initial connection to the server is not secure and the TLS handshake only occurs after a command is issued by the client.

openssl s_client -tls1_2 -crlf -connect test.sockettools.com:21 -starttls ftp

The -starttls smtp option is what tells OpenSSL that you want to connect as an FTP client using explicit TLS. If you need to test a connection to an FTP server using implicit TLS on port 990, then simply exclude the -starttls ftp option from the command.

Checking Mail Servers

Because most mail servers use explicit TLS, you will need to use the -starttls option and specify which mail protocol you're testing. Here's an example of what the command would look like connecting to an SMTP server:

openssl s_client -tls1_2 -crlf -connect outlook.office365.com:587 -starttls smtp

This would connect to the Office 365 mail server on port 587, the standard submission port. You could also specify port 25 or an alternative port if needed.

To check a connection with an IMAP server, you would use this command:

openssl s_client -tls1_2 -crlf -connect outlook.office365.com:143 -starttls imap

And to check a connection with a POP3 server, you would use this command:

openssl s_client -tls1_2 -crlf -connect outlook.office365.com:110 -starttls pop3

If you want to check a connection which uses implicit TLS, then simply omit the -starttls option and specify the correct port number. For example, the implicit TLS port number for POP3 is 995, so the command would look like this:

openssl s_client -tls1_2 -crlf -connect outlook.office365.com:995

Interacting with the Server

After you've connected, you can also interact with the server by sending commands and checking the response, with the OpenSSL tool handling the encryption and decryption for you. This is similar to how developers used to use Telnet to check a connection to a service and then issue commands to see how it would respond.

If you do this, just keep in mind that you must send commands in the format the server recognizes. If you're testing a connection with a web service, you could manually compose a request and see the response. However, be aware that most servers have timeout limits which will cause them to drop the connection if there's no activity over a relatively brief period of time.

You may need to compose your request in a text editor, and then copy and paste the request. The OpenSSL tool reads standard input and writes to standard output, so you can also redirect input from a text file.

For example, create a new file named http-request.txt and add the following lines:

GET /client HTTP/1.0
Host: test.sockettools.com
Accept: text/*
Connection: close

This simple request can be used with our test server and will return information about the connection back to the client. Because of how HTTP requests are structured, make sure there is an extra blank line at the end of the file. This tells the server it's reached the end of the request header block.

Next, use the OpenSSL command to send the request to the server:

openssl s_client -tls1_2 -connect test.sockettools.com:443 < http-request.txt

The output will not only provide information about the secure connection itself, but will also return the output from the request. You could also redirect the output to a different text file and analyze it in your favorite text editor.

If you're having a problem connecting with a server, this approach can help you isolate whether it's an underlying networking problem, a security related problem (such as the server having an invalid certificate) or a protocol-level problem where the server is simply not recognizing certain commands.

See Also

Creating a Certificate Using OpenSSL
Connections Fail Using Test Certificate