What Is Client Certificate Authentication? | JSCAPE (2024)

Overview

How do you strengthen a server's user authentication system? Well, one solution would be to simply add another authentication method. Most servers authenticate users through the usual username-password technique. If you can augment that with another method, you'll be able to make it more difficult for unauthorized users to break in. For servers whose users connect through Web browsers, one option would be something called client certificate authentication. Let's explore what this is.

Why Add Another Method Of Authentication?

When used properly, like when you enforce strong passwords and keep them secret, username-password login systems can actually provide an adequate layer of security. Unfortunately, in the real world, password best practices are rarely enforced.

When that happens, username/password login systems become quite vulnerable. There are also cases when, in spite of strong password policies, password authentication systems can still fall to a skilled and persistent attacker. Passwords can be compromised through brute force attacks or a variety of social engineering techniques.

One way to strengthen user authentication on your server is to augment password authentication with another form of authentication. You see, authentication can be implemented in different ways or factors:

• By asking information only the user should know (a password or a passphrase)
• By asking something only the user should have in his possession (use a private key and a public key, SSL certificate or card, or a digital certificate)
• By asking for something that's physically part of the user (a thumbprint or retinal scan)

When you combine two factors of authentication (something the user knows AND something the user has), the result is 2-factor authentication. You can also combine more factors and come up with a multi-factor authentication.

Combining two or more factors of authentication makes it significantly more difficult for an attacker to succeed. That's what happens when you augment password authentication with client certificate based authentication. If an impostor manages to acquire a user's username and password, he would still have to overcome another challenge — getting hold of something that's supposed to be in the possession of that user. That is the client certificate.

Getting hold of either one — a username/password or a ssl/tls certificate — can already be quite difficult. Using both makes it exponentially more difficult?

What Is A Client Certificate?

A client digital certificate or client certificate is basically a file, usually protected with a password and loaded onto a client application (usually as PKCS12 files with the .p12, .pfx, .pem extension).

Note: For those familiar with SFTP keys, client certs are similar to them.

Your certificate would typically contain pertinent information like a digital signature, expiration date, name of client, name of CA certificate (Certificate Authority), revocation status, SSL/TLS version number, serial number, and possibly more, all structured using the X.509 standard.

At the start of a SSL or TLS session, the server (if configured to do so) may require the client application to submit a client certificate for authentication. Upon receiving the certificate, the server would then use it to identify the certificate's source and determine whether the client should be allowed access.

Popular Web browsers like Firefox, Chrome, Safari, and Internet Explorer can readily support client certificates. These digital certificates can also be loaded unto secure file transfer clients like AnyClient as well as to other client applications that support SSL/TLS-protected protocols like HTTPS, FTPS, WebDAVs, and AS2.

If a server is enabled with client certificate authentication, only users who attempt to connect from clients loaded with the right client certificates will succeed. Even if a legitimate user attempts to connect with the right username and password, if that user isn't on a client application loaded with the right client certificate, that user will not be granted access. In fact, if that user is connecting from a Web browser, the login page (where they're supposed to enter their username and password) might not even load at all like the one shown below.

Don't confuse client certificates with server certificates. Both are digital certificates that involve client and server applications but they're two different things. A server certificate is sent from the server to the client at the start of a session and is used by the client to authenticate the server. A client certificate, on the other hand, is sent from the client to the server at the start of a session and is used by the server to authenticate the client.

Of the two, server certificates are more commonly used. In fact, it's integral to every SSL or TLS session. Client certificates are not. They're rarely used because:

1. They have to be installed on client machines/applications (making them tedious for system admins) and
2. Most client end users are non-technical and don't want to be bothered.

Today, however, with ever-growing threats on the Web, it would be wise to employ client certificate authentication for sensitive Web sessions.

If you want to know how clients (Web browsers in particular) authenticate servers using server certificates, I suggest you read the post An Overview of How Digital Certificates Work.

As soon as you're done with that, let's discuss how client certificate authentication works.

How Client Certificate Authentication Works

Client certificate authentication (if ever applied) is carried out as part of the SSL or TLS handshake, an important process that takes place before the actual data is transmitted in a SSL or TLS session. Here's a simplified illustration that includes that part of the process.

1. First, the client performs a "client hello", wherein it introduces itself to the server and provides a set of security-related information.
2. The server responds with its own "server hello", which is accompanied with its server certificate and pertinent security details based on the information initially sent by the client.
3. This is the optional step that initiates client certificate authentication. This will only be carried out if the server is configured to request a digital certificate from the client for the purpose of authentication.
4. Before this step is performed, the client inspects the server certificate for authenticity. If all goes well, it transmits additional security details and its own client certificate.

Only after both server and client have successfully authenticated each other (in addition to other security-related exchanges) will the transmission of data begin.

We know from the blog article, An Overview of How Digital Certificates Work, how the client is able to validate the server certificate and authenticate the server. So how does the server authenticate the client?

Just like in server certificate authentication, client certificate authentication makes use of digital signatures. For a client certificate to pass a server's validation process, the digital signature found on it should have been signed by a CA recognized by the server. Otherwise, the validation would fail.

In future posts, we'll show you how to generate client certificates on a secure file transfer server and import those certs on Firefox, Safari, Chrome, and Internet Explorer.

Get Your Free Trial

Would you like to try this yourself? JSCAPE MFT Server is platform-agnostic and can be installed on Microsoft Windows, Linux, Mac OS X and Solaris, and can handle any file transfer protocol as well as multiple protocols from a single server. Additionally, JSCAPE enables you to handle any file type, including batch files and XML. Download your free 7-day trial of JSCAPE MFT Server now.

Related Content

How To Create A Client Certificate

How To Setup An AS2 Server With JSCAPE: A QuickStart Guide

Three Ways To Generate OpenPGP Keys

Setting Up SFTP Public Key Authentication On The Command Line