Simply Put: How Does Certificate-Based Authentication Work?

I find a few universal truths when mentioning certificates to people. Most people I speak with consider them to be a very secure concept almost without fail. However upon mentioning that I want to talk about certificates: that person’s face turns a slightly lighter shade, their eyes get a bit wider, and they have this immediate fight or flight instinct kick in 🙂

I can tell you, this is a subject that does not have to be scary, there are just a few misunderstandings.  One such example of a common misunderstanding:

“Since the Certificate was issued by Active Directory’s Certificate Authority, then authenticating that certificate is the same as an Active Directory authentication”

I realize how and why that assumption was made, it gets awfully confusing to try and separate out Active Directory from a Certificate Authority when they are so tightly integrated.  However, let me assure you, standard Certificate Authentication is the same, regardless of whether the CA is built by Microsoft, Cisco, Symantec, Entrust, etc.

Let’s take some time & review how Certificate-Based Authentications actually work.  When presented with a certificate, an authentication server will do the following (at a minimum):

  1. Has the Digital Certificate been issued/signed by a Trusted CA?
  2. Is the Certificate Expired – checks both the start and end dates
  3. Has the Certificate been revoked?  (Could be OCSP or CRL check)
  4. Has the client provided proof of possession?

Let’s examine the above 4 items one at a time:

Has the Digital Certificate Been Signed by a Trusted CA?

The signing of the certificate really has two parts.  The first part is the certificate must have been signed correctly (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.  Using Cisco ISE as an example, the trusted certificate will need to have the “Trust for client authentication” use-case selected (as seen below).

Trust for Client Authentication


So not only does ISE “trust” certificates that have been signed by this CA, it trusts those for a specific use-case (client authentication).  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.

Has the certificate expired?

Just like a drivers license or a passport, a certificate will have 2 dates listed in it: a date issued, and date it is valid to (when does it expire). Fun story:  I was in Las Vegas for a conference.  I was out drinking with my girlfriend at the time and a few friends and we went into the ICE bar at Mandalay Bay to sample some very cold Vodka.  When we presented our ID’s, my North-Carolina issued Drivers license was expired.  The picture was still a valid picture of me, the name was still mine, and my birth date showed that I was of legal drinking age – yet I was refused service because the license expired and was therefore no longer a valid source of identity.  “Access-Reject” 😛

An authentication server does the same sort of check.  Is the certificate valid for the date and time that the authentication request comes in.  This is one reason why Network Time Protocol (NTP) is so important when working with certificates.  Many of us have seen problems where time was out of sync.  For example: a certificate was presented on January 10th 2014 at 11:11am, but its “valid-from” value started on January 10th at 11:30am.  This was because of a time sync issue where the Certificate Authority thought it was 20 minutes later than the authentication server, and the brand-new certificate was not valid yet!  🙂  This is so common you would laugh (or cry).  See in the following image that the certificate has a valid-from and valid-to attribute.

Valid Date Range

Has the cert been revoked?

You are driving down the road, and you are pulled over by a policeman.  The policeman asks for your drivers license and proof of insurance.  You hand the officer a driver’s license, which is immediately checked for evidence of authenticity, i.e.: does it look like a valid driver’s license or a forgery.  Ok, it’s not fake, Check.  Next, expiration: it is not expired.  Check.  Now the policeman asks you to wait there, while he goes back to his squad car.

While in the squad car, the officer will perform some authorization checks (are you a registered owner of the car you were driving, etc.).  Those are not important for this conversation, though.  What is important is that the policeman must make sure your VALID drivers license was not revoked by the DMV.  A quick look-up on the computer into the DMV records shows that your drivers license was revoked for too many DWI’s.  The cold steel of the handcuffs and the rough shove into the back seat of the Squad car as you are hauled off to jail make you re-evaluate your life choices.

Certificate Authentication has the same capability (not the handcuffs, I’m talking about the look-up into the DMV to revocation status).  Every certificate authority should also have a service to publish a list of certificates that have been revoked.  There are 2 main ways to do this today:

  • Certificate Revocation List (CRL).  This is basically 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 was revoked already.   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 today, because it provides near real-time updates.  OCSP allows the authentication server to send a real-time request (like a http web request) to the  service running on the CA or another device and checking the status of the certificate right then & there.  OCSP could be compared to the policeman using the computer in the squad car & doing a look-up into the DMV’s database.

If the certificate has been revoked, then access is denied.  Enjoy the lights and sirens on the way to jail.  🙂

Here is an example of the configuration screen for Certificate Authority in Cisco ISE.  You have the ability to configure where to check for OCSP and/or CRL, when a certificate is signed by this particular root (or it’s subordinates).

Certificate Validation Services

I feel it’s very important for you to understand that checking for certificate revocation is an option.  You’ll notice neither CRL or OCSP are on by default, they require the admin to configure the URL or the service location.  It is also critical to understand what behavior will happen if the service is not available or the status of the certificate is unknown.  I.e.: 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.  You can see that in the image listed below.

CRL URI in Cert














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”.  That 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.  Think of it this way, if you are pulled over by a policeman for speeding.  You hand the policeman a drivers license:

  • It’s a valid Drivers License, issued by a trusted root (the state DMV)
  • It has not expired yet, so that is no problem
  • The policeman calls into the DMV and the drivers license has not been revoked.

But, the picture on the drivers license is a picture of a woman with long flowing brown hair and hazel eyes; yet you yourself are a bald elderly man.  OOPS.  This “valid” drivers license was not issued to you – the proof of possession has failed!  Again – jail time!  🙂

Certificate authentications do something similar.  There will be some throw away piece of data that must be encrypted and decrypted.  Successfully encrypting and decrypting that data ensures that the client has both the public and private keys, and therefore it is the proof of possession.  This ensures that someone did not just grab the client’s public key & try to present that as being their own.  If the client cannot provide proof of possession, then the authentication will fail – Access-Reject.

So, What did any of this have to do with Active Directory?

Aaron, you started this Blog off discussing people’s misconceptions about certificates and AD, where were you going with that point?

Thanks for bringing me back on topic.  What can often confuse people with regard to AAA is the difference between authentication and authorization.  They often blend so much.  A certificate issued by Active Directory Certificate Services is still just an x.509 certificate.  It will go through all the authentication validation listed above, regardless of the fact that the CA was integrated into AD.

What is possible, is to examine a field of the Certificate & then to do a separate look-up into AD based on that field during the authorization phase.  For example, a certificate with a subject of Aaron is sent via EAP-TLS.  The certificate is validated through the four functions that I discussed, and it passes.  Now it’s time for the authorization.  The RADIUS server (ISE in my 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.  The image below shows that CAP.  If you are using a different RADIUS server, consult the administrative guide for that solution for a similar function.  Note:  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 will be to deny-access.

Mapping Cert Field to Username

Please note, 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 and identity-enabled firewalls, and other services.  If the authentication was a certificate-based authentication (EAP-TLS) 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, etc.

Well, I hope this provided you with a nice, and easy to follow overview of Certificate Authentication.  As always, your comments are more than welcome!