Many people understand that certificates are very secure. It’s hard to find anyone who thinks otherwise. Yet, people have a profound sense of unease whenever the subject of certificates comes up. They seem to believe that certificates are extremely complex monsters that only someone with advanced technical knowledge can understand. This need not be the case. In this article, we will discuss how certificate-based authentication works.
Using a public-key certificate, a computer can securely identify itself over a network, in a process known as certificate-based authentication. This cryptographic technique is incredibly important, yet incredibly misunderstood. It is the basis of many security protocols, including SSL/TLS, which browsers use to authenticate transactions.
There are some misconceptions that we need to clear up. One of the most frequent misconceptions is that certificate-based authentication is the same as Active Directory authentication. This misconception stems from the fact that the certificate is issued by the Certificate Authority of the Active Directory.
Active Directory’s and the Certificate Authority are intimately intertwined, so it’s not so surprising that people get the two entangled to the point of believing that Active Directory authentication is the same as certificate-based authentication. However, what you need to understand is that certificate-based authentication is the same regardless of who built the Certificate Authority.
So how does certificate-based authentication work?
When an authentication server is presented with a certificate, it will, at a minimum, verify the following facts
- Has the certificate been issued or signed by a Trusted Certificate Authority?
- It will check the start and end dates to see if the certificate has expired.
- Through the Online Certificate Status Protocol (OCSP), or Certificate Revocation List (CRL), the revocation status of the certificate will be checked.
- Finally, proof of possession from the client will be required.
Has the certificate been issued or signed by a Trusted Certificate Authority?
The first part of signing a certificate is checking if the certificate has been correctly signed. The second part is checking that the signing was done by a Trusted Certificate Authority. So, for instance, let’s say you are an animal clinic using Cisco ISE, a trusted certificate must have the “Trust for client authentication” use-case selected for this part of the process to be done successfully.
Has the certificate expired?
The issue date and expiry date will be checked to see if the certificate has expired. If it has, you will receive an “Access-Reject” response to your request. This explains why Network Time Protocol is so important. WIthout it, it would be impossible to verify expiry dates.
Has the certificate been revoked?
Now, your certificate may not have expired, and it may have been signed correctly by a Trusted Certificate Authority, but that isn’t the end of the road. The next step is to check that your certificate hasn’t been revoked. Certificate-based authentication will involve the use of Certificate Revocation Lists, or Online Certificate Status Protocol (OCSP), to see if your certificate is on the list of revoked certificates.
Have you provided proof of possession?
Finally, the authentication server will check if the certificate is truly yours. You will be asked to complete various bits of encryption and decryption as proof of possession. Failure to do so will result in a failure of authentication.
