• What is Certificate-Based Authentication

    Back to GlossaryBack to Glossary

    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

     As shown above here are the relevant details of the certificate based authentication flow:

    • Client will initiate connection to the server.
    • The server will respond and provide the server’s public certificate to the client.
    • The client will perform some validation to make sure the server’s public certificate is trusted.
    • The server requests the certificate from the client.
    • A nonce is signed by the client using the client’s private key, and is returned to the server and also includes the client’s public certificate.
    • The server receives both the certificate and the signed nonce.Using the client’s public certificate the server will verify that the nonce was signed by the client.
    • The server checks that the certificate has not expired and that it also has not been revoked.
    • If all the verifications have passed the server may map attributes of the certificate to a user in their system to identify and authenticate the user.

    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.

    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. A client 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 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.

    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 issue user certificates to hardware-based authenticators such as the YubiKey and never allow the private key to be created or exported outside of the YubiKey. When deploying a PKI always secure the Certificate Authority (CA) private key in a Hardware Security Module (HSM) such as the YubiHSM 2. Never accept private keys be stored in software or on disk.
    • 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.
    • Always consider the use a Certificate Management System (CMS) such as Versasec vSEC:CMS or Intercede MyID when deploying certificate-based auhtentication at scale; A CMS streamlines and helps enforce best-practice processes around authenticator lifecycle such as Issuance, Renewal and Revocation and allows an organization to integrate with different data sources, change default management keys, set PIN policies and more.

    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.

    Peace of mind and flexibility

    for less than a cup of coffee per user/month

    Get YubiEnterprise SubscriptionGet YubiEnterprise Subscription

    Get started

    Find the right YubiKey

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

    Contact salesContact sales
    Get protected today

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

    Shop nowShop now