What is Certificate-Based Authentication?
Certificate-based authentication is a phishing-resistant cryptographic technique which enables computers to use digital certificates to securely identify each other across a network.
Certificate-Based Authentication Definition
Certificate-based authentication (CBA) has been a staple of government agencies and other high security environments for decades, long before the invention of FIDO U2F and FIDO2, mostly due to its reliability and effectiveness in physical environments. To this day, it remains a favorite amongst many security experts, and is still being deployed across countless industries for a variety of scenarios. A couple of notable examples of its ubiquity include the humble smart card often used for access to offices and other buildings, the widely used SSL/TLS protocol featured in web browsers, and CBA is even found in any implementation of Public-Key Infrastructure (PKI). Generally speaking, client certificate-based authentication refers to an end user’s device proving its own identity by providing a digital certificate that can be verified by a server in order to gain access to a network or other resources.
What Is Certificate-Based Authentication?
In a nutshell, certificate-based authentication (CBA) uses a digital certificate derived from cryptography to identify a user, device or machine, before granting access to an application, network or other resource. Unlike some authentication solutions that are targeted at humans, such as one time passwords (OTP) and biometrics, certificate-based authentication can be adopted for all endpoints, including servers, personal computers, e-passports and literally anything that may be classified under the Internet of Things (IoT).
CBA is a much more secure alternative than the traditional username and password combination, although it may also be used in concert with traditional methods for the purposes of strong user authentication, to create a form of phishing-resistant MFA. Since the digital certificate resides on an individual’s device or computer alongside the private key, it enables the user’s browser or client to log into various systems automatically without much additional effort from the user, since it can simply be presented when requested.
In general, client certificate-based authentication and other methods where the secret is never exposed to even the user, is preferable to password-based authentication. Username and password authentication is based only on what the user knows (the password), but certificate-based client authentication also leverages what the user has (the private key), which cannot be phished, guessed or socially engineered.
But it is also important to highlight some of the conditions that help to maintain this level of control:
- no unauthorized users have gained access to the private-key underlying the digital certificate
- the lifecycle of distributed certificates is properly managed, including registration, renewal and revocation
- the proper infrastructure is set up to support the sending and validation of certificates
Users must be especially vigilant in protecting private keys in addition to the physical security of their devices generally speaking, but parties responsible for the infrastructure to support CBA also have their part to play in the process.
How Does Certificate-Based Authentication Work?
A digital identity certificate is an electronic document used to prove private key ownership. Certificate-based authentication uses the information within said document to verify the user, device or machine, in contrast to the classic username and password combination which is strictly limited to verifying only those who are in possession, i.e. potentially not just the user who should have access. The increased sophistication of attacks, coupled with the exploding number of attack surfaces as more and more devices access the network, make this additional capability more necessary than ever.
A digital certificate contains a number of important details, depending on the standard in use. For example, the popular X.509 certificate includes the below elements:
- The public key
- The user or device’s name
- The name of the Certificate Authority (CA) that issued the certificate
- The date from which the certificate is valid
- The expiry date of the certificate
- The version number of the certificate data
- A serial number
When implemented correctly, digital certificate-based authentication makes it possible for security administrators to issue digital certificates to new users, renew certificates that have expired for existing users, and finally, revoke certificates from users who no longer should have access.
A certificate-based authentication server usually follows some variation of the below process in order to validate a client request:
- The server checks that the current date is valid, and the certificate has not expired
- The server sends random bits of data, also known as a nonce, to be signed by the requesting device
- The nonce is signed by the requesting device using its private key, and is returned to the server alongside its certificate
- The server receives both the certificate and the signed nonce, and then validates the user’s identity by signing the original nonce itself using the public key stated within the certificate, and comparing that result with the received signed nonce
- If the results match, the user is authenticated and granted access
There are usually even additional layers of verification in addition to the above process, such as examining the signature of the CA that issued the certificate, and climbing that hierarchy of signatures all the way to the root CA, to verify that it is known and trusted by the server. Verification of someone or something’s claimed identity is at the heart of authentication, so it is vital to highlight that client authentication certificates are digital files that are primarily used to restrict system access to a subset of users or devices only, not as a means to verify an identity per se. It does, however, make machine-to-machine communication and user authentication much more secure within a larger security context.
User authentication is vital to access management and the development of a zero-trust architecture for enterprises. To prevent unauthorized employees, non-employees, and potentially random people from accessing enterprise servers, networks, apps or other digital resources, digital certificates can ensure users who request access to protected resources or sites are legitimate. Public Key Infrastructure (PKI) and certificate-based authentication achieves this goal without standard password-based login protocols for the most part. Under this approach, users are not requested to enter their password again once they’ve initially logged into their device, but instead, their identity is presumed linked to either their own digital attributes or their machine’s identity, and submitted to the designated server for verification.
Digital certificates are the central elements of Public Key Infrastructure (PKI), and these objects serve as “ID cards” for users and devices in the digital world. Just like a traditional form of ID, each digital certificate can be differentiated from others based on its unique characteristics. They are trusted because users and devices must first validate their identity prior to issuance, and then obtain the certificate via a publicly trusted and reputable third party known as a Certificate Authority (CA), or to carry on with the ID card metaphor, a recognized institution such as the Department of Motor Vehicles (DMV) or a town hall issuing a marriage license.
A CA reviews Certificate Signing Requests (CSR), or in layman’s terms, the documentation submitted for new digital certificates, and validates the information against official resources to ensure it is legitimate. Aclient authentication certificate is issued only once the CA has verified the claimed identity and has ensured that everything matches up.
Local and private CAs also exist, and some companies opt to issue client authentication certificates of their own instead of opting for a widely recognized CA such as IdenTrust or DigiCert. Private certificate issuance is different because there is obviously no prerequisite for information verification by a publicly trusted CA, and as a result, private client authentication certificates aren’t publicly trusted and should never be used to secure access to external (public-facing) resources, only internal-facing ones.
Overall, PKI can be thought of as the framework for cryptographic technologies, such as digital certificates and public-private key pairs, processes and policies to operate in concert, in order to enable secure communications over a network.
Certificate-Based Authentication vs
Token Based Authentication
Token-based authentication should not be confused with certificate-based authentication, although they may seem similar on the surface. Token-based authentication protocols allow users to verify their identity against an Identity Provider (IdP), and in exchange, receive a unique access token signed by the IdP. Users can then access any app or other resource associated with said service provider during the lifespan of the token, such that each time they revisit they don’t need to re-enter or present their credentials, only the token.
Authentication tokens work much like a ticket stub to an ongoing event. As long as the token remains valid, the user retains access – or using the original analogy, as long as the event is ongoing, the ticket stub can always be redeemed for re-entry to the venue. A certificate-based authentication scheme under the same scenario, would perhaps be more akin to retaining the original ticket and perhaps even the receipt.
In technical terms, the key difference between certificate-based authentication and token-based authentication is that clients are not required to retain or protect a private key under a token based authentication scheme. Only the IdP’s private key is applicable under token-based authentication, as it is that signature that needs to be verified in order for the issued token to be valid.
Certificate-Based Authentication Pros and Cons
There are many pros to how certificate-based authentication works:
- When enabled by cloud technology, the entire digital certificate-based authentication process can take place virtually. There is no hardware required, in contrast to traditional smart cards which require readers or terminals.
- Cost-effective virtual digital certificate management options make it easier, quicker, and cheaper to issue, replace and revoke certificates than ever before.
- By enabling the user to employ Single Sign-On (SSO), certificate-based authentication can eliminate several initial steps in a traditional authentication process.
- Digital certificate-based authentication is phishing-resistant, user-friendly and convenient compared to passwords.
- CBA can enable mutual authentication. All parties involved in the communication must identify and authenticate themselves, making it easier for administrators to identify potentially suspicious or unwarranted activity.
- Finally, CBA is infinitely extensible, such that external users such as vendors, partners, contract-based employees and freelancers, can be provisioned access by simply issuing a new certificate, without impact upon existing users.
Cons of certificate-based authentication:
- Although establishing a digital network infrastructure for certificate-based authentication is a one-time process and cost, it is not cheap. For many start-ups and smaller companies, it may simply not be a feasible option.
- The ongoing maintenance of CBA must always be considered, including issuance, renewal and revocation. This includes operating and licensing fees for a Certificate Management System (CMS), for instance.
- Digital certificates are not always transferable between products and vendors, as they tend to be vendor specific. This means certificates may be incompatible with some devices and systems, although this may change in the future, for example, with Microsoft soon to be expanding support.
Certificate-Based Authentication Benefits
It takes time to set up certificate-based authentication, but in the long run, it is significantly more secure and provides an overall intuitive user experience. If implemented properly, PKI certificate based authentication offers many benefits:
- Simplifies the authentication process. CBA doesn’t require hard-to-remember or confusing passwords for the client. When employees don’t need to remember passwords, it’s easier for authorized users to access privileged services and sites. Additionally, this reduces IT support costs and employee frustration.
- Reduces insecure password practices. Post-it notes with passwords left on a desk and shared account logins become a relic of the past.
- Password attacks like brute force and rainbow table are no longer a threat. With no user passwords, there’s no brute force target for hackers.
- Phishing-resistance. By eliminating passwords that can be phished, intercepted, stolen, shared or compromised in other ways, organizations can shut down another very common attack vector.
- Extensible to external users. CBA makes it easy to roll certificates out to users outside the organization who may need access to the network, such as independent contractors, partners, vendors, and freelancers. They won’t need much additional training or any additional software either.
- Responsive to change. Because certificates are managed centrally, actions such as issuance or revocation will enact an associated response to the corresponding access immediately.
- Implements better access controls and the principle of least privilege. Enterprises should restrict access to only the devices and users that require it, to reduce risk of exposure. By leveraging existing permissions and policies to control which machines and users can access various networks and applications, CBA can protect those that are critical and sensitive.
- Moves an enterprise toward a zero-trust architecture. Trust no one automatically and always verify, by requiring all users and devices to authenticate using certificates, not passwords.
- Greater security. Certificate-based multi-factor authentication in conjunction with a Trusted Platform Module (TPM), is more secure than token- and SMS-based MFA methods alone.
- No additional hardware needed. Although most secure in conjunction with a TPM such as found on a smart card, most certificate-based solutions today are known for ease of deployment, ongoing management, and often come with a cloud-based management platform. Certificates are stored locally on the machine or device, so unlike some authentication methods such as OTP tokens or biometrics, no additional hardware is needed. This saves on costs and reduces management time spent on issuing, replacing, distributing and revoking tokens.
- User-friendly. Increased security and its associated costs always have the potential to burden end users. Fortunately, certificates are very easy for end users, because there is nothing to do after a certificate is installed, and most enterprise solutions support certificate-based authentication out of the box.
- Mutual authentication. Certificates allow for mutual authentication, where both parties involved in a transaction can be identified. This makes it easier for administrators to flag potentially suspicious or unwarranted activity if an unknown identity or perhaps an identity known to have been compromised but not revoked, is engaging in network transactions.
Best Practices for How to Implement Certificate-Based Authentication
It is important to properly manage the technologies and processes that enable certificate authentication within your organization. Here are some client authentication management best practices:
- Create a policy for certificate management operations. This should be a quick, go-to resource for internal management of certificates, including which CAs to use, which personnel has the authority to manage certificates within the organization, what management tools or applications to use, and which users should be given permissions.
- Always keep private keys secure. Store private keys securely using a TPM or Hardware Security Module (HSM). Private keys should never be stored in cleartext or on public-facing servers.
- Create a certificate lifecycle plan. It is critical to properly manage the certificate lifecycle in order to maintain up-to-date access information across the enterprise. Part of this process is ensuring the processes are in place to manage the impact of a certification revocation by a CA for instance, or when and how to renew any certificates close to expiration.
- Update user permissions regularly. Improper access management can be disastrous as it can create a vulnerability to be exploited by attackers. No one should still have access privileges for sensitive systems if they are no longer in a role that requires it.
- Use a comprehensive management tool for certificate-based authentication. A CMS affords visibility into the entire IT environment and all of its digital certificates and keys, all in a centralized platform.
Does Yubico Offer Certificate-Based Authentication Protection?
YubiKey provides Smart Card functionality based on the NIST-specified Personal Identity Verification (PIV) interface. The YubiKey can also perform ECC or RSA sign/decrypt operations using a stored private key, based on commonly accepted interfaces such as PKCS11.
The YubiKey smart card minidriver provides smart functionality above and beyond the baseline authentication functionality of the YubiKey, including certificate and PIN management, support for ECC key algorithms, and private key use policy. YubiKey users can generate a self-signed certificate, request a certificate from a CA, or import an existing certificate.
You can even set up a Certification Authority (CA) with subordinate CA private stored keys to sign certificates. Or support OS X code signing by generating a certificate on the YubiKey, submitting the certificate request to Apple, and loading the certificate to the Apple Keychain.
Find out more about Yubico’s Certificate-Based Authentication protection here.