What is Certificate-Based Authentication?

Certificate-based authentication is a cryptographic technique that enables computers to use documents called public-key certificates, to securely identify each other across a network.

Certificate-Based Authentication Definition

Certificate-based authentication is a feature of the widely used SSL/TLS protocol, but is even found in many other internet security protocols. This is most apparent in web browsers for instance, which will use certificates to authenticate online transactions and alert users if they are attempting to reach an untrusted or unverified site. However, more generally speaking, client certificate-based authentication refers to an end user’s device proving its own identity by sending a certificate, in order to gain access to a network or other resources. This is in contrast to SSL/TLS specifically, which involves servers confirming their identities to client devices.

What Is Certificate-Based Authentication?

Certificate-based authentication uses a digital certificate to identify a user, device, or machine, before granting application, network, or resource access. Unlike some solutions that only work for users, such as one time passwords (OTP) and biometrics, certificate-based authentication can be used for all endpoints, including the Internet of Things (IoT).

Certificate-based authentication is a more secure alternative to the traditional username and password combination, although it might also be used in tandem with traditional methods for user authentication. It enables the user’s browser or client to log in to various systems automatically using a saved digital certificate from their individual device or computer.

In general, client certificate-based authentication 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), in addition to what the user knows (the password guarding the private key).

Only the right conditions can maintain this level of control:

  • no unauthorized users have gained access to the client password or machine
  • the client software private key database password is set
  • the software is set up to automatically request the password at a reasonably frequent pace

Neither password-based nor certificate-based authentication address unauthorized physical access to passwords or individual machines, and the security issues those dangers can cause. Public-key cryptography merely verifies whether the public key in a certificate and the private key used to sign data correspond. Users must still be vigilant in  protecting private keys, and the physical security of their devices generally speaking.

How Does Certificate-Based Authentication Work?

A digital identity certificate is an electronic cryptographic document used to prove private key ownership. Certificate-based authentication can verify the user, device, or machine, in contrast to the username and password combination whose capabilities are limited to verifying whoever possesses them, not just the user who should have access. The increased sophistication of attacks, coupled with the exploding numbers of attack surfaces as more and more devices access the network, make this additional capability more necessary than ever.

Digital certificate-based authentication authenticates a user, device, or machine with a digital certificate before granting it access to the resource or network. Digital certificate-based authentication makes it possible for network administrators to renew certificates for existing employees, issue digital certificates to new employees, and finally, revoke certificates from employees who have left.

A certificate-based authentication server uses a single sign on process and certificates to authenticate in steps:

  • The client digitally signs a piece of data using a private key
  • The signed data and the client’s certificate are both sent across the network
  • The destination server receives both the certificate and the signed data, and then authenticates the user’s identity by comparing the sign data with the public key stated within the certificate
  • If the results match, the user is authenticated and allowed network access

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.

how CBA works diagram

User authentication is vital to access management and the development of a zero-trust security architecture for businesses. To prevent unauthorized employees, non-employees, and 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, before they are ultimately granted access to them. Public Key Infrastructure (PKI) certificate-based authentication achieves this goal for instance, without standard password-based login protocols. Under this approach,users are not requested to enter their password again once they’ve already logged into their device, but instead, their identity is linked to either their own digital attributes or their machine identity, and submitted to the designated server for verification.

Digital certificates are trusted, critical elements of Public Key Infrastructure (PKI). These files 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 mostly because prior to issuance, users and devices  must first validate their identity, and then attain them via a publicly trusted and reputable third party, known as a Certificate Atuthority, or CA.

A CA reviews Certificate Signing Requests (CSR), the paperwork and documentation submitted for new digital certificates, and validates that information against official resources to ensure it is legitimate. It then issues the client authentication certificate only once it has verified the claimed identity and has ensured that everything matches up.

Local, private CAs do also exist, and some companies opt to issue client authentication certificates of their own through them. Private certificate issuance is different because there is obviously no prerequisite for information verification by a publicly trusted CA. 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 resources.

Overall, PKI  can be thought of as the framework for cryptographic technologies (including digital certificates and public-private key pairs), processes and policies to operate in concert, in order to enable secure communications over the internet.

Traditional server authentication involves that same SSL/TLS handshake mentioned above. This handshake allows two parties to exchange information in a private conversation, encompassed within an encrypted, secure communication channel that cannot be intercepted by unintended parties.

(There are technical differences between the two types of TLS handshakes currently in use, TLS 1.2 and TLS 1.3, but that is a more granular discussion than is required here.)

Below is a simplified, high-level view of what this process entails:

  • The client reaches out to the server with a request to start a conversation, usually triggered by the user entering an address in their browser. 
  • The server immediately sends the client its SSL/TLS certificate in response to the initial request. This contains CA-verified domain information and a public key so that the client is able to verify the claimed identity. The client does this by computing the necessary cryptographic checks on the server certificate received to ensure they are authentic and were legitimately issued by the attributed CA, and then agrees to engage in a handshake..
  • The client encrypts a session key using the server’s public key, and sends it back to the server.
  • The server decrypts the client’s message with its private key, and the session can now be established with both parties in possession of a shared session key.
  • The parties finally switch to the new, agreed encrypted channel. First the client switches, with the server following.
  • Once the session is concluded (i.e. the user leaves the website), the session keys are discarded.

The standard handshake initially relies upon asymmetric encryption because it is quite often regarded as the most secure way to publicly exchange information. However, public key encryption requires using two unique but related keys, itself a practice that is a drain on overhead due to the associated constant validation required. This is in part why the client and server switch to using just one key within a symmetric encryption scheme, after authentication takes place for the session, since it is more efficient for data encryption and decryption at-scale.

PKI client authentication takes place in several similar but distinct steps:

  • The device starts the process of attempting to gain access to a protected resource such as an internal website or a service by initiating an HTTPS connection.
  • As with a traditional TLS handshake, the service or site sends the client a copy of its own SSL/TLS certificate in response. But this time, the server and device exchange PKI certificates, because the site or service will also request the device’s public key and client authentication certificate in order to verify its claimed identity.
  • First, the client verifies that the server certificate is legitimate and valid (has not expired) by tracing the SSL/TLS certificate back to the original issuing (root) certificate. The process proceeds if it matches, but if not, the connection will be terminated immediately.
  • Then the client sends the web server its client authentication certificate to enable the server to verify the user certificate is legitimate and valid. Similar to a trusted server certificates, trusted user certificates contain a digital signature and were signed by a cryptographic public key traceable to an issuing CA.
  • The user’s identity and authorization are verified by the server against the requested resource. It is important to associate a certificate with a user’s individual identity because if the user or device profile lack permissions for an associated resource, the server should refuse the connection.
  • The server will deny or allow access to the resource based on the authentication process. Only a device or service that can successfully establish a secure, encrypted connection with the server, and subsequently verify each others’ identities successfully, should ultimately gain access to specific resources.

Always note: The high level of security enabled by certificate-based authentication, will depend largely on users and devices maintaining security over the physical devices and private keys within the network. For example, you can never leave a device—and more importantly, the authentication credentials it holds—open and vulnerable to use and access by unauthorized users, otherwise it could result in said node being compromised and having unwarranted trust to infiltrate the rest of the network.

Certificate-Based Authentication vs

Token Based Authentication

Token-based authentication protocols allow users to verify their identity in exchange for a unique access token. Users then access an app or website during the lifespan of the token that it was issued for, so that each time they revisit any resource protected with that same token, they don’t need to re-enter credentials.

Auth tokens work 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. 

There are other differences between a token based authentication and an API certificate based authentication.
Certificates are based on public-key cryptography and use a set of asymmetric keys. The client retains and protects the private key, which is never shared. The public key goes to the Certificate Authority (CA) where it is signed and stamped into a certificate.

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 some biometric-based authentication methods.
  • Cost-effective virtual digital certificate storage also makes it easier, quicker, and cheaper to issue, replace, and revoke certificates.
  • By allowing the user to employ the SSO method, certificate-based authentication can replace several initial steps in the traditional authentication process.
  • Digital certificate-based authentication is user-friendly and convenient.
  • Enables 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.
  • Digital certificates enable easy extension to, and communication with, external users such as vendors, partners, contract-based employees and freelancers, and any others who may require secure network access.

Cons of certificate-based authentication:

  • Although establishing a digital network of certificate-based authentication for mobile devices 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.
  • Digital certificates may not be able to distinguish between products and vendors as they usually tend to be vendor specific. This means these certificates may be incompatible with some devices and machines.

Certificate-Based Authentication Benefits

It takes more time to set up certificate-based authentication, but in the long run it is significantly more secure and it saves time. If implemented properly, PKI certificate based authentication offers many benefits:

  • Simplify the authentication process. 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 time and employee frustration.
  • Reduce insecure password practices. Certificate-based authentication basically makes notes with passwords left on an open desk and shared account logins a relic of the past.
  • Password attacks like brute force and rainbow table are no longer a threat. With no user passwords, there’s really no brute force target for hackers.
  • Phishing proof. By eliminating passwords that can be phished, intercepted, stolen, shared or compromised in other ways, organizations become more phishing proof.
  • Extends to external users. It’s easy to roll certificates out to users outside the organization who may need to 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. For example, revoking complete access for individual users that leave the company by invalidating their certificate will disable all associated access.
  • Implement better access controls and the principle of least privilege. Restrict access to only the devices and users that require it to reduce risk of exposure. Leverage existing permissions and access control policies to control which machines and users can access various networks and applications, while protecting those that are critical and sensitive.
  • Move toward a zero-trust infrastructure. Trust no one automatically and require all users to authenticate using certificates, not passwords.
  • More secure. Certificate-based multi-factor authentication in conjunction with a trusted platform module (TPM), may be more secure than token- and SMS-based MFA methods alone.
  • No additional hardware needed. Although most secure in conjunction with a TPM, most certificate-based solutions today are known for ease of deployment and ongoing management, and 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 replacing, distributing, and revoking tokens.
  • User-friendly. Increased security and its associated costs always have the potential to burden end users. Certificates are very easy for end users, because there is nothing to do after the certificate is installed, and most enterprise solutions already support certificate-based authentication.
  • Mutual authentication. Certificates allow for mutual authentication, where both parties in a communication 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, is engaging in network transactions.

Best Practices for How to Implement Certificate-Based Authentication

outline of people and a key

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 have permissions.
  • Keep private keys secure. Store private keys securely using a TPM or HSM. Private keys should never be stored on public-facing servers.
  • Create a plan in case of certificate revocation. It is critical to properly manage the certificate lifecycle. 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. 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 cert based authentication. Certificate managers should offer visibility into the entire IT environment and all of its digital certificates and keys. They should also offer a centralized platform for certificate lifecycle management.

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 perform ECC or RSA sign/decrypt operations using a stored private key, and based on commonly accepted interfaces.

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 end entity 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.

Peace of mind and flexibility

for less than a cup of coffee per user/month

Get started

Find the right YubiKey

Contact our sales team for a personalized assessment of your company’s needs.

Get protected today

Browse our online store today and buy the right YubiKey for you.