What Is Client Certificate Authentication?

Posted by John Carl Villanueva on Sun, May 31, 2015 @ 09:54 AM


How do you strengthen a server's user authentication system? Well, one solution would be to add another. 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 impostors to break in. For servers whose users connect through Web browsers, one option would be something called client certificate authentication. Let me explain what it 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 a respectable 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 a.k.a. factors:

  • By asking information only the user should know (e.g. a password or a passphrase)
  • By asking something only the user should have in his possession (e.g. a key, a card, or a digital certificate)
  • By asking something that's physically part of the user (e.g. a thumbprint or retinal scan)

When you combine two factors of authentication (e.g. 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 n multi-factor authentication.

Combining 2 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 something is the client certificate. 

Getting hold of either one - a username/password or a digital certificate - can already be quite difficult. How much more getting hold of both? 

What is a client certificate?

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

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

A client certificate would typically contain pertinent information like a digital signature, expiration date, name of client, name of CA (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. 

Actually, 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's 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's connecting from a Web browser, the login page (where he's supposed to enter his 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 (and hence tedious for system admins) and
  2. most client end users are non-technical folks who don't want to be bothered with that kind of stuff.

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 in 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 An Overview of How Digital Certificates Work how the client is able to validate the server certificate and authenticate the server. So the remaining million-dollar question is - 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 our succeeding 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. Stay tuned for that!

Get Started

JSCAPE MFT Server is a secure file transfer server that supports several protocols protected by SSL/TLS, including HTTPS, FTPS, WebDAVs, and AS2. It also comes with a Key Manager where you can create your own client certificates. Oh and yes, it also supports client certificate authentication.

Download a free, fully-functional evaluation edition now.

Download Now


Topics: Security, Secure File Transfer, FTPS