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.\nAuthentication 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\u2019s device sends a certificate to prove its identity so the user can gain access to server or network resources.\nBenefit of cert-based authentication\nBecause 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\u2019s Active Directory and Cisco\u2019s ISE.\nIn this article, we\u2019ll give you a high-level view of how certificate-based authentication works. First, we\u2019ll offer a brief introduction to public-key cryptography, and then we\u2019ll step through the process of a specific certificate-based authentication example.\nPublic-key cryptography and certificates\nPublic-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\u2014numbers 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\u2019ll send to you.\nPublic 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 firstname.lastname@example.org, proving you have admin rights over the domain. Once you\u2019ve proved you are who say you are, you\u2019d generate a key pair and send your public key to the CA, who would then integrate it into your certificate.\nTogether, 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\u2019s certificate before it allows you to make a purchase, to ensure that you\u2019re sending your credit card number to the company you think you\u2019re sending it to.\nBut 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\u2019re only letting trusted clients access internal resources.\nHow client certificate-based authentication works\nIf you\u2019re 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.\nWhen a client attempts to connect to a corporate network, the network\u2019s authentication server must answer the following questions:\n\nHas the digital certificate been issued and signed by a trusted CA?\nIs the certificate valid at the time of attempted network access?\nHas the certificate been revoked?\nHas the client provided proof of possession?\n\nLet\u2019s examine these one at a time, using a transaction with Cisco ISE as an example.\nHas the digital certificate been issued and signed by a trusted CA?\nThe first thing that needs to be ascertained is whether the certificate has been signed properly\u2014following the correct format, etc. If it is not, it will be discarded immediately. Next, the signing CA\u2019s 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 \u201cTrust for client authentication\u201d use-case selected.\nISE needs to trust both the CA that\u2019s signed this certificate and the specific use case for which it\u2019s been designated (client authentication, in this case).\u00a0 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\u2019s exactly like someone entering in the wrong password.\nIs the certificate valid at the time of attempted network access?\nJust like a driver\u2019s 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\u2019re at a bar and present an ID past its expiration date, it won\u2019t matter that it includes your correct name, birth date, and photo. It\u2019s no longer a valid confirmation of identity, and your drink order will receive an \u201cAccess-Reject\u201d response.\nAn 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\u2019t uncommon. For example, a certificate may be presented on January 10, 2021, at 11:11 a.m., but its \u201cvalid-from\u201d value might begin on January 10 at 11:30 a.m. due to a time sync issue where the CA\u2019s server is 20 minutes ahead of the authentication server.\u00a0\nHas the cert been revoked?\nImagine you\u2019re pulled over by a police officer.\u00a0 You hand the officer your driver\u2019s license, which passes tests for authenticity (it\u2019s not forged) and expiration (it hasn\u2019t expired).\u00a0 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\u2019s license was revoked for too many DWIs.\u00a0\nCertificate 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.\u00a0 There are two main ways to do this:\nCertificate Revocation List (CRL): This is a signed list that the CA publishes on a website that can be read by authentication servers.\u00a0 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\u2019s cert has been revoked already. A CRL could be compared to the policeman having a list of suspended drivers in his squad car.\nOnline Certificate Status Protocol (OCSP): This is the preferred method for revocation checks in most environments because it provides near real-time updates.\u00a0 OCSP allows the authentication server to send a real-time request (like an HTTP web request) to the\u00a0 service running on the CA or another device, checking the status of the certificate right then and there.\u00a0 OCSP could be compared to the policeman using the computer in his squad car to perform a look-up in the DMV database.\nIf the certificate has been revoked, then access is denied.\u00a0\nIt\u2019s important to note that checking for certificate revocation is optional. You\u2019ll 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 \u201cfail-open\u201d or \u201cfail-closed\u201d?\nThe client\u2019s 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.\nHere\u2019s another interesting factoid about managing revocation lists. In the previous section where we discussed the certificate expiration, we looked at the fields \u201cValid-From\u201d and \u201cValid-to\u201d. 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.\nHas the client provided proof of possession?\nThis is a way for an authentication server to be sure the client truly owns the certificate.\u00a0 Returning for the moment to our policeman analogy: you\u2019re pulled over and hand over your license.\n\nIt\u2019s a valid driver\u2019s license, issued by a trusted root (the state DMV)\nIt has not expired yet\nThe policeman calls into the DMV and learns that the driver\u2019s license has not been revoked\n\nBut 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 \u201cvalid\u201d driver\u2019s license was not issued to you\u2014the proof of possession has failed!\nCertificate authentications do something similar. The process includes some throwaway piece of data that must be encrypted and decrypted\u2014and 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\u2019re 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.\nAuthentication vs. authorization\nIt\u2019s 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.\nBut 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.\u00a0 For example, imagine a certificate with the subject of Aaron that\u2019s been validated through the four functions we discussed. Now it\u2019s 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.\nCisco ISE uses something called a Certificate Authentication Profile (CAP) to examine a specific field and map it to a user-name for authorization.\u00a0 Figure 5 shows that CAP.\u00a0 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.\u00a0 If the account were disabled in AD, then the authorization result will be to deny-access.)\nAll 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.