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 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).

READ MORE HERE