TLS and its predecessor, SSL are cryptographic protocols to provide communication security (confidentiality and integrity in some cases and non-repudiation in other cases) over a network.

In one-way TLS, or regular TLS, the X.509 server certificate is created by a CA that the client can trust when wants to connect. Public Key Infrastructure (PKI) is responsible for trust management and distribution of the certificate(s). Certificate Authorities (CAs) play a very important role in PKI. An X.509 certificate is nothing but some information about the server and the public key of the server that is digitally signed by a CA.

A server can be configured to allow connections from any client (like in one-way TLS) or it can be configured to ask any clients that attempt to connect to it to get authenticated. So, for a client to authenticate, it involves a client certificate. In two-way TLS authentication, aka TLS with client certificate authentication, client certificate is also involved in addition to the server certificate for hardening the authentication process. Just like a server certificate, a client certificate contains basic information about the client’s identity, its public key and the digital signature of a CA on this certificate verifies that this information is authentic. The client certificate should be signed by a CA that the server trusts and it is obvious that both X.509 certificates should exist prior to the connection!

One way TLS is secure enough when you use it with Authentication, something you face when you want to login to Gmail. When you use Gmail web interface, you use one-way TLS via a browser https capability in addition to your password. If you do not use your password, only you can verify that you have been connected to a legitimate server but Gmail server can not verify your identity so we can not say the connection is secure. If Gmail offers a two-way TLS, you can easily connect to it without entering your password and the connection is considered secure.

The main intent to use a two-way TLS connection would be when a server should only accept TLS connections from a limited group of allowed clients. An example can be a scenario where an organization wants to limit TLS connections to a server to only be coming from the organization’s legitimate partners or customers. Definitely IP whitelisting for the clients is not a good security practice because the IP can be spoofed.

To simplify the process of 2way TLS handshake, we can say

  1. A client sends a request to access to protected information on the server.

2. The server presents its X.509 certificate to the client.

3. The client verifies the server’s certificate by validating the digital signature of server’s public key using CA’s public key.

4. If the last step is successful, the client sends its certificate to the server.

5. The server verifies the client’s certificate using the same approach in step 3.

6. If successful, the server gives access to the protected information to the client.

If you need to configure an Apache web server to handle two-way TLS, consult this document: http://www.robinhowlett.com/blog/2016/01/05/everything-you-ever-wanted-to-know-about-ssl-but-were-afraid-to-ask/

Information Security Expert, Cyber Security Engineer, Blogger, Mentor, PCI SME, CISM, CISA, CRISC, RHCSA, MCSE, CCNA, MBA, PMP, CLSSGB

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store