With a reported 65% of people reusing their passwords, and an ever-increasing number of accounts requiring secure logins, it’s clear that an alternative to password-based authentication is necessary. Digital X.509 certificates are an intriguing alternative – like photo IDs, they’re tied to one specific user or device and don’t require users to remember complex passwords.
Passwordless authentication has become a bit of a meaningless buzzword these days, but certificates make it achievable and secure our digital identities. In this article, we’ll examine what a public key certificate can be used for, the sophisticated cryptography that makes them so secure, and what you need to implement them on an organization-wide scale.
What is an X.509 Certificate?
In short, an X.509 certificate is a widely used digital certificate format based on the security of asymmetric cryptography and an interface language called Abstract Syntax Notation. Imagine them as similar to a photo ID; anyone can use a simple password, but certificates are bound to one specific person or device, like a photo ID. Instead of authenticating by typing in a password, the device proves it’s authorized with its certificate through transport layer security protocols. X.509 certificates are also often used to verify sites and servers based on the Internet Engineering Task Force (IETF) standards.
These certificates are generated and managed by a type of infrastructure called a Public Key Infrastructure (PKI). PKIs are comprised of multiple pieces, including Certificate Authorities (CAs) and a Certificate Revocation List (CRL). A root CA is at the core, and its main purpose is to provide an authoritative source for its intermediate CAs, which are in turn used to issue X.509 certificates to individual users or devices.
Public Key and Private Key Pairs: How Certificates Work
Every X.509 certificate is based on a common principle: asymmetric cryptography, which is also sometimes referred to as public key cryptography. This type of cryptography uses a key pair comprised of a public key and a private key. The use of this key pair is why X.509 certificates are sometimes also referred to as public key certificates.
Cryptographic key pairs are essentially long strings of numbers that are mathematically related to each other. Together, the public key and private key can be used to decrypt and encrypt data sent by and to the X.509 certificate holder. The public key is used to encrypt the data, while the private key, on the other hand, is used to decrypt the encrypted data from the public key.
Private keys and public keys play two vital and separate roles, but the private key is especially important. A private key is what proves the user’s identity because only the party that has access to the private key can use it. Public keys are sent to the public – exactly as the name implies. Anyone can have access to the public key certificate’s public key.
Importance of Certificate Key Storage
Storing the cryptographic key pairs securely is vital – especially the private halves. There are different strategies for storing them safely, but one of the best is to ensure that they’re generated and kept on the device requesting a certificate at all times. This is often done with the use of a special cryptographic processor called a Trusted Platform Module (TPM).
Key storage is a complicated topic and is especially crucial for any CA certificate since the CA certificate allows CAs to issue certificates in response to a certificate request. You can read more in-depth information about the topic in our research about key storage methods.
Common X.509 Certificate Fields & Attributes
An X.509 certificate is comprised of certificate fields and attributes that provide information about the user, the certificate issuer, and the cryptographic parameters of the certificate itself. These certificate fields are laid out in what’s referred to as an X.509 certificate template. The templates can vary – depending on the public key infrastructure, you may be able to customize the templates as necessary.
However, there are many attributes that are commonly used, and we’ll define some of the more common ones below.
- Subject/Subject Alternative Name (SAN): The name of the user or device the certificate is being issued to.
- Serial Number: The serial number is an identifying number the issuing certificate authority assigns to each certificate it issues. Some PKIs allow you to search by certificate serial number to find specific certificates.
- Signature Algorithm: The private key’s algorithm, which is usually RSA 2048.
- Subject Public Key Information: The public key linked to the certificate.
- Validity Period: A date range in which the certificate is considered valid.
- Issuer: The issuing CA’s name.
- DNS: Used to imprint the certificate with the device’s information.
- Other Name: User principal name. This field is usually used to indicate the user’s identity for Wi-Fi connections specifically.
- Enhanced Key Usage: What the certificate is being used to authenticate for.
You can easily see an X.509 certificate yourself right now. Secure websites are issued X.509 certificates by a widely trusted certificate authority to verify the site is who it says it is. As an example, you can go to any website – including this blog’s page – and click the lock icon by the URL.
X.509 Certificate Use Cases & Applications
An X.509 certificate can be used for numerous applications besides verifying website identity. The technology behind Public Key Infrastructure has a plethora of use cases in organizations today, including the following:
Secure Email Signatures
Secure/Multipurpose Internet Mail Extensions (or S/MIME, for short) is when a Public Key Infrastructure is used to enroll an email client for an X.509 certificate. Thanks to the technology of public and private keys, S/MIME can verify the identity of senders and encrypt the messages being sent.
In practice, an email sent by someone using S/MIME will be marked with a ribbon icon to prove that the sender is who they say they are and that the contents of the email have not been tampered with. This is especially important for preventing phishing attacks. It also provides the technology for a secure digital signature.
Client Authentication
One especially popular use for digital certificates is client authentication. Put simply, client authentication is when the X.509 certificate key pair is used in place of a password to log in to a protected resource, verifying digital identities.
Cloud applications, VPNs, and even wired or wireless/Wi-Fi internet access are examples of things you can use digital certificates to authenticate.
Code Signing
Just as emails can be secured with digital certificates, so, too, can code – and it functions similarly. With an X.509 certificate, developers can apply digital signatures to their applications, certifying that the application hasn’t been tampered with.
Most applications in mobile app stores, such as the Apple App Store and the Google App store, have to receive this type of X.509 certificate before they can list their applications in the store. However, code signing certificates can also be used in a private sense with an internal certificate authority to verify for users within an organization that an application provided by their organization is secure.
Document Signing
X.509 certificates can also be used to digitally sign documents in addition to emails and code. By applying unique digital signatures to a document, and encrypting those digital signatures with the certificate’s private key, anyone who looks at the document can be sure it is authentic. Document signing is an excellent way to protect the integrity of valuable digital documents.
Web Servers
Finally, digital certificates see wide use in web server security. They can ensure users only contact legitimate servers – and therefore legitimate pages – as opposed to fake or insecure ones that could steal their information.
As we mentioned above, you can find any website’s certificate by clicking the lock icon in front of the URL in your browser. These are called Secure Sockets Layer (SSL) certificates.
Stages of the X.509 Certificate Lifecycle & Public Key Infrastructure Components
Enrollment
A user cannot generate a certificate themselves. They must enroll for an X.509 certificate by requesting one from a certificate authority. Because individuals have their own differing levels of technical literacy, this can be challenging – and it would be time-consuming for administrators to do this manually for every device.
This is why onboarding technology is crucial for certificate management. With the right services, administrators can leverage much of their existing infrastructure for this process. For devices managed by MDMs such as Intune or Jamf, Simple Certificate Enrollment Protocol (SCEP) can be used to issue X.509 certificates automatically to devices without any end-user input.
Unmanaged devices/BYODs can be trickier. However, there are onboarding services, such as our JoinwNow MultiOS, that can help end-users enroll for their own X.509 certificates in a matter of minutes.
Validation & Authentication
An X.509 certificate needs to be authenticated by something, which is often a RADIUS server. RADIUS servers, in short, are similar to virtual guards at the door. They can check that an X.509 certificate is valid and turn away any devices that lack a valid certificate, denying access to your wireless and wired networks or VPNs.
Certificate-based RADIUS authentication generally follows these steps:
- Checking that the X.509 certificate is within its validity period (unexpired)
- Checking that the certificate’s revocation status on the CRL
- Sending the device an ACCESS_ACCEPT or ACCESS_DENY packet based on the previous steps.
Cloud RADIUS takes it a step further with identity lookup. After steps one and two, Cloud RADIUS can also check your Identity Provider in real-time and apply policies based on information contained in the X.509 certificate template.
Revocation
At the end of its lifecycle, an X.509 certificate should be revoked. The reasons for revocation can vary based on your organization’s policies. Some may revoke certificates when they’re not used to authenticate for a specific period of time, others may revoke certificates after lengths of time called validity periods.
When an X.509 certificate is revoked, it’s added to the Certificate Revocation List (CRL). As more revoked certificates are added in time, abbreviated CRLs called delta CRLs may also be used. Some PKIs may also use Online Certificate Standard Protocol (OCSP) instead to revoke certificates, which is common for web servers.
What is the Simplest Way to Deploy Certificate-Based Authentication?
While many organizations agree that X.509 certificates are a more secure alternative to passwords for verifying digital identities and more, including Microsoft, there’s been hesitation to adopt them. Building a PKI on your own is difficult, requiring expertise, time, and resources.
But you don’t need to build a PKI on your own. With a managed PKI service like SecureW2’s, your organization can deploy a full PKI quickly while relying on our team of experts. We provide you with everything you need to go truly passwordless, including a Cloud RADIUS server to authenticate your X.509 certificates and onboarding technology to issue them to both managed and unmanaged devices.
If you’d like to learn more, reach out to us today for a demo so we can show you our passwordless platform in action.
