How does certificate-based authentication work?

Certificate-based authentication is a cryptographic technique that allows one computer to securely identify itself to another across a network connection, using a document called a public-key certificate.

Authentication using certificates is a feature of many internet security protocols, including the near-universal SSL/TLS, commonly used by web browsers to authenticate online transactions. However, while most SSL/TLS uses involve servers confirming their identities to client machines, the term certificate-based authentication usually denotes a situation where that scenario is reversed: an end user’s device sends a certificate to prove its identity so the user can gain access to server or network resources.

Benefit of cert-based authentication

Because public-key cryptography is considered very secure, certificate-based authentication is often used to complement password-based authentication, in essence providing two-factor authentication without requiring the end user to fiddle with a security key fob or receive a code on their cell phone. Certificate-based authentication is integrated into many corporate networking and network-security tools, like Microsoft’s Active Directory and Cisco’s ISE.

In this article, we’ll give you a high-level view of how certificate-based authentication works. First, we’ll offer a brief introduction to public-key cryptography, and then we’ll step through the process of a specific certificate-based authentication example.

Public-key cryptography and certificates

Public-key cryptography is a topic that can quickly get the reader involved in some head-spinning mathematics that are beyond the scope of this article. But at its core is the concept of cryptographic keys—numbers that are used in concert with a complex algorithm to encrypt and decrypt data. Into order to participate in an encrypted conversation, a user generates a pair of keys, one private and one public. The two will be related by some mathematical operation that is difficult to reverse; for instance, a private key might be two very long prime numbers, and the corresponding public key would be the result of multiplying those two primes together. Messages can be encrypted with the public key, but only decrypted with the private key. This means that you can share your public key with anyone you want to communicate with, safe in the knowledge that only you or someone else with access to your private key can decrypt the messages they’ll send to you.

Public keys are generally shared by means of certificates. These electronic documents include not just the public keys themselves, but a suite of other information about owner of the certificate. Certificates are issued by certificate authorities (CAs), organizations whose business is confirming the identities of those requesting certificates. For instance, if you wanted a certificate for the domain example.com, you might need to correspond with a CA from an address like hostmaster@example.com, proving you have admin rights over the domain. Once you’ve proved you are who say you are, you’d generate a key pair and send your public key to the CA, who would then integrate it into your certificate.

Together, public key encryption techniques and CAs who issue certificates make up the public key infrastructure, or PKI. PKI underlies the SSL/TLS protocol that secures the open internet. For instance, your browser would need to verify an e-commerce site’s certificate before it allows you to make a purchase, to ensure that you’re sending your credit card number to the company you think you’re sending it to.

But your web browser can also store certificates of your own as well, allowing a server to verify your identity. This is less important in most situations on the internet, but comes in handy for corporate networks that want to ensure they’re only letting trusted clients access internal resources.

How client certificate-based authentication works

If you’re running an e-commerce website and need a digital certificate, you generally buy one from one of the broadly accepted trusted CAs, lists of which are built into commercial OSes and web browsers. This can be true for client certificates as well; but client certificates may also be issued by the owner of the corporate network that the clients will be accessing, with the network management or security software acting as a CA.

When a client attempts to connect to a corporate network, the network’s authentication server must answer the following questions:

1. Has the digital certificate been issued and signed by a trusted CA?
2. Is the certificate valid at the time of attempted network access?
3. Has the certificate been revoked?
4. Has the client provided proof of possession?

Let’s examine these one at a time, using a transaction with Cisco ISE as an example.

Has the digital certificate been issued and signed by a trusted CA?

The first thing that needs to be ascertained is whether the certificate has been signed properly—following the correct format, etc. If it is not, it will be discarded immediately. Next, the signing CA’s public key must be in a Trusted Certificates store, and that certificate must be trusted for purposes of authentication. For our example, the trusted certificate will need to have the “Trust for client authentication” use-case selected.

ISE needs to trust both the CA that’s signed this certificate and the specific use case for which it’s been designated (client authentication, in this case).  If a client presents a certificate, and that certificate has not been signed by a CA that is trusted for client authentication, then the authentication will fail. It’s exactly like someone entering in the wrong password.

Is the certificate valid at the time of attempted network access?

Just like a driver’s license or a passport, a certificate will have two dates listed in it: a date it was issued, and a date when it expires. If you’re at a bar and present an ID past its expiration date, it won’t matter that it includes your correct name, birth date, and photo. It’s no longer a valid confirmation of identity, and your drink order will receive an “Access-Reject” response.

An authentication server does the same sort of check. Is the certificate valid for the date and time when the authentication request comes in? This is one reason why Network Time Protocol (NTP) is so important when working with certificates, because problems where time is out of sync aren’t uncommon. For example, a certificate may be presented on January 10, 2021, at 11:11 a.m., but its “valid-from” value might begin on January 10 at 11:30 a.m. due to a time sync issue where the CA’s server is 20 minutes ahead of the authentication server. 

Has the cert been revoked?

Imagine you’re pulled over by a police officer.  You hand the officer your driver’s license, which passes tests for authenticity (it’s not forged) and expiration (it hasn’t expired).  But the officer might go back to his car to make one more kind of check. A quick look-up on the computer into DMV records shows that your driver’s license was revoked for too many DWIs. 

Certificate authentication has the same sort of capability to check revocation status. Moreover, every certificate authority should have a service that publishes a list of certificates that have been revoked.  There are two main ways to do this:

Certificate Revocation List (CRL): This is a signed list that the CA publishes on a website that can be read by authentication servers.  The file is periodically downloaded and stored locally on the authentication server, and when a certificate is being authenticated, the server examines the CRL to see if the client’s cert has been revoked already. A CRL could be compared to the policeman having a list of suspended drivers in his squad car.

Online Certificate Status Protocol (OCSP): This is the preferred method for revocation checks in most environments because it provides near real-time updates.  OCSP allows the authentication server to send a real-time request (like an HTTP web request) to the  service running on the CA or another device, checking the status of the certificate right then and there.  OCSP could be compared to the policeman using the computer in his squad car to perform a look-up in the DMV database.

If the certificate has been revoked, then access is denied. 

It’s important to note that checking for certificate revocation is optional. You’ll notice in Figure 3 that neither CRL nor OCSP are on by default; they require the admin to configure the URL or the service location. It is also critical to understand what will happen if the service is not available or the status of the certificate is unknown: How does the authentication policy handle exceptions? Is it configured to “fail-open” or “fail-closed”?

The client’s certificate itself will have an extension called CRL Distribution Points, which can be populated with the URI where the authentication server may locate the CRL.

Here’s another interesting factoid about managing revocation lists. In the previous section where we discussed the certificate expiration, we looked at the fields “Valid-From” and “Valid-to”. These fields form the validity period, which defines the period of time that the signing CA warrants it will maintain revocation information regarding that certificate. This helps keep CRL and OCSP lists at manageable sizes.

Has the client provided proof of possession?

This is a way for an authentication server to be sure the client truly owns the certificate.  Returning for the moment to our policeman analogy: you’re pulled over and hand over your license.

• It’s a valid driver’s license, issued by a trusted root (the state DMV)
• It has not expired yet
• The policeman calls into the DMV and learns that the driver’s license has not been revoked

But on the license is a picture of a woman with long flowing brown hair and hazel eyes; yet you are a bald elderly man. This “valid” driver’s license was not issued to you—the proof of possession has failed!

Certificate authentications do something similar. The process includes some throwaway piece of data that must be encrypted and decrypted—and remember, doing that requires possession of both the public and private keys in a key pair. Proof of possession is established in the following way. By successfully completing the encryption and decryption, you’re proving that someone did not just grab your public key and try to present it as being their own. If the client cannot provide proof of possession, then the authentication will fail.

Authentication vs. authorization

It’s important to keep in mind the difference between authentication and authorization. The process outlined above follows the vendor-neutral procedures of PKI-based authentication; the user certificate is a standardized X.509 certificate, even if the CA that issued it was integrated into your local Active Directory network.

But it is possible to examine a field of the certificate and then to do a separate look-up into AD based on that field during the authorization phase.  For example, imagine a certificate with the subject of Aaron that’s been validated through the four functions we discussed. Now it’s time for the authorization. The RADIUS server (ISE in our examples) will take the certificate subject (Aaron) and do a look-up into AD for that username. This is where group membership and other policy conditions will be examined, and the specific authorization result will be issued.

Cisco ISE uses something called a Certificate Authentication Profile (CAP) to examine a specific field and map it to a user-name for authorization.  Figure 5 shows that CAP.  If you are using a different RADIUS server, consult the administrative guide for that solution for a similar function. (Note that Cisco ISE will also do a courtesy-check to validate if the machine or account has been disabled in AD.  If the account were disabled in AD, then the authorization result will be to deny-access.)

All this is a very different process than an Active Directory authentication, which uses Kerberos, and therefore AD logs will be recorded differently. There are solutions on the market that examine AD log files and use that information to help tie together usernames and IP addresses for single-sign-on to web proxy servers, identity-enabled firewalls, and other services. If the authentication was certificate-based, but the user was authorized from an AD look-up, that process will most likely not provide the right types of logging for those identity-enabled firewalls or web proxies.