Simply put: How does certificate-based authentication work?

Let's take some time and review how certificate-based authentications actually work.

Become An Insider

Sign up now and get FREE access to hundreds of Insider articles, guides, reviews, interviews, blogs, and other premium content. Learn more.

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 and 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 Auth Aaron Woland

Figure 1 - 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 Dates Aaron Woland

Figure 2 - Validity Period

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.

To continue reading this article register now

Now read: Getting grounded in IoT