Share This Article
Today’s hybrid work environments provide a lot of flexibility for employees, but managing access and authentication can cause headaches for IT departments. Stolen, hacked, or shared passwords are major vulnerabilities for your network. Using certificates is a powerful way to improve your security and streamline operations.
In this post, we’re going to look at how using X.509 certificates as part of RADIUS protocols makes the authentication process better for everyone.
Understanding X.509 Certificates
X.509 certificates enable secure access and communications by automatically establishing identity and encrypting data. There are a lot of different use cases for X.509 certificates, including automating network and device access, securing online customer transactions, and enforcing digital signatures.
Using X.509 certificates with RADIUS protocols makes the network authentication process more efficient by eliminating the need for individual user passwords. It lays the foundation for other Zero Trust strategies like single sign-on (SSO) or multi-factor authentication (MFA).
Definition and Importance
X.509 certificates are digital documents issued by a certificate authority (CA) that verify the identity of organizations, individuals, and websites through use of a public key. Once the CA verifies the identity of the entity through the public key, data is exchanged and decrypted through use of a private key that facilitates secure communications.
Think of X.509 certificates like a digital ID card. It’s used from machine to machine to confirm identity and prevent breaches like man-in-the-middle (MITM) attacks.
Components of an X.509 Certificate
Let’s look at the elements at work in a X.509 certificate. These components combine to enable the processes of authentication and encryption.
- Version number: specifies the build of the certificate in use. The most recent is V9.1, introduced in 2021. V3 remains the most commonly used, because of its flexibility with extensions.
- Serial number: a unique number issued for each certificate by the CA.
- Signature algorithm: specifies the algorithm that is used to sign the certificate. For example, RSA with SHA-256.
- Issuer field: identifies the organization that issued the certificate. In most cases, this is a publicly trusted CA like GoDaddy, GlobalSign, or Amazon Trust Services. Public CAs come preinstalled in most modern devices, so they are automatically trusted. Organizations issue their own private CAs to handle employee Wi-Fi access, VPNs, or internal applications.
- Subject: identifies the website, organization, user, or even a device that the certificate represents. There are several fields within a subject that form the distinguished name (DN), such as domain names, organization name, and geographic information.
- Public keys: used to verify data that comes from the certificate owner. It enables encryption and secure connections.
- Extensions: only available in x.509 V3 and offer additional functions like specifying key usage or using alternative names.
- Signature: a unique digital identifier created by the private key. The public key information is decrypted and extracted from the signature to confirm an identity is valid.
How X.509 Certificates Work
X.509 certificates use a public key infrastructure (PKI) framework to provide authentication. The process starts with the creation of a certificate, then goes through the verification process to establish a chain of trust where all identities are validated. Let’s take a more detailed look at each of the steps.
Certification Process and Verification
The process begins with the creation of a public-private key pair. The entity that requested the certificates then generates a certificate signing request (CSR) that contains the entity’s public key and identifying data. The CSR is then sent to a CA that checks the digital signature against the CA’s known public key.
During this step, a chain of intermediate certificates leads back to a trusted root CA contained inside a trust store. Once the CA successfully validates the identifying information in the public key, the CA signs with its private key, issuing an X.509 certificate.
RADIUS protocols utilize the same process to validate and authenticate root CA certificates contained in its trust store, then grants access to devices or users requesting access to the network.
Certificate Chains and Cross-Certification
Certificates form a trust hierarchy starting with the root certificate. CAs down the tier issue intermediate certificates on behalf of the root, creating a chain of trust. The chain guarantees that even if a lower-tier certificate is presented it can be traced back to the universally trusted root CA.
Cross-certification builds on the process by allowing different CA hierarchies to identify each other’s certificates. Cross-certification is useful when dealing with distributed networks and different regions that may not share a common root CA.
Public Key Infrastructure and Usage
X.509 certificates are issued through the framework of public key infrastructure (PKI) that creates, manages, and validates public and private key pairs. PKI frameworks rely on CAs to issue certificates, registration authorities (RAs) for verification, and certificate revocation lists (CRLs) or the Online Certificate Status Protocol (OSCP) for revocation.
In a network using RADIUS security, PKI usage replaces the need for password-based authentication. RADIUS validates certificates using PKI by checking the CA certificates in the trust store and verifying the certificate is valid, then grants access automatically.
RADIUS PKI enables scalability with tools that automate the creation of certificates and can be applied to any devices on an organization’s network. This simplifies credentials management and communication between devices and leads to improved security for organizations and individual users.
Certificate Fields and Instructions
Each X.509 certificate contains a number of identifying fields. Following the instructions in the fields enables systems like RADIUS to ensure certificates are only being used as intended. Here’s a look at some of the key fields and instructions.
- The Common Name (CN) field identifies the entity on the certificate, for example, a website or the name of a device on an organizational network. CN guarantees secure communications with a specific server.
- Subject Alternative Name (SAN) allows other identities to match to the CN for environments that require multiple domains or IP addresses.
- Key Usage defines the cryptographic operations the certificate is authorized for, like digital signatures or certificate signing.
- Extended Key Usage (EKU) gives even more specificity to operations and might include tasks like server authentication or client authentication. EKU is a key component of RADIUS operations that need to differentiate between server certificates versus client certificates.
- The Issuer field identifies the CA that provided the certificate. It can include the root CA or any intermediate CA along the chain.
- Validity period indicates the start time that the certificate is valid and the expiration date.
RADIUS servers automatically enforce policies through the use of field data and instructions. Adding optional fields to handle areas like Online Certificate Status Protocol (OCSP) URLs provide more controls for automating access, compliance, and security.
Major Protocols Using X.509 Certificates
X.509 certificates are the standard for many major protocols because of the flexibility, compatibility, and security they provide. Here are some of the protocols that use X.509 certificates.
- TLS (Transport Layer Security) uses X.509 to authenticate servers and clients, then facilitates encrypted online communications.
- HTTPS uses certificates to verify the authenticity of websites and browsers, to protect data like passwords, credit cards, or other sensitive information.
- S/MIME (Secure/Multipurpose Internet Mail Extensions) use X.509 to sign and encrypt emails.
- X.509 certificates are used within SAML (Security Assertion Markup Language) to enable SSO, by allowing identity providers and service providers to exchange authentication data securely.
- EAP-TLS (Extensible Authentication Protocol – Transport Layer Security) is used in RADIUS protocols to authenticate client devices and RADIUS servers, enabling access without the use of passwords.
Creating and Implementing X.509 Certificates
Creating an X.509 certificate starts by generating a public-private key pair. Most often, these tasks are done automatically using software, or cloud-based RADIUS platforms.
In some cases, certificates are manually created by IT admins through tools like OpenSSL or PKI software. In hybrid situations, the initial setup is performed by IT, then automated scripts or software is used to issue and renew certificates.
After the key pair is created, a CSR is generated and submitted to the CA which verifies the identity of the entity and issues an X.509 certificate.
Implementing X.509 certificates centralizes identity management and reduces time spent on password resets and related troubleshooting tasks for IT teams. They also make network access easier for verified users and reduce the risk of compromised passwords and phishing attacks.
In RADIUS environments, certificates are issued to user devices, like smartphones or laptops, and the RADIUS server validates them against a trust store of certificates from a known CA.
Generating Self-Signed Certificates
Self-signed certificates are created without using a CA. Usually they’re only used internally or for testing since there is no outside authority to confirm their authenticity. Self-signed certificates are more cost-effective than using a CA, but should only be deployed in controlled environments because of security concerns.
Self-signed certificates can be a good solution for internal resources like intranet sites or private databases, Internet of Things (IoT) devices, and short-term projects.
Small businesses can take advantage of cost savings by deploying self-signed certificates to authenticate internal RADIUS environments like private employee Wi-Fi networks or VPNs.
Certificate Signing Requests (CSR)
A CSR is a request from a website, device, or user to obtain an X.509 certificate from a certificate authority. CSRs are created with OpenSSL, enterprise PKI systems, or certificate management software. The CA uses the information about the entity in the CSR to authenticate and validate, then issues an X.509 certificate.
Certificate Authority (CA) Roles
Certificate authorities can be public or private. Public CAs are trusted automatically in most current operating systems, browsers, and applications. Websites, e-commerce platforms, and public APIs all typically utilize public CAs. Private CAs are issued for internal use by organizations. They authenticate employees on private networks and secure devices and communications. Both public and private CAs use certificate revocation lists (CRLs) or the Online Certificate Status Protocol (OCSP) to revoke compromised certificates.
CAs play a key role in RADIUS-based authentication. RADIUS servers are configured to trust specific root or intermediate CAs, then client devices or users present certificates issued by the trusted CA for authentication. For Wi-Fi authentication, both the RADIUS server and client use certificates to ensure mutual trust.
Managing and Maintaining X.509 Certificates
X.509 certificates need to be maintained so networks and secure communications continue to operate smoothly. Expiring certificates can lead to disruptions and vulnerabilities if not renewed.
Tracking expiration dates, planning renewals, monitoring trust stores, and revoking compromised certificates are all part of managing X.509 certificates. Automatic controls can handle most tasks, but sometimes IT teams are needed for troubleshooting, custom certificates, or to take care of policy updates within an organization.
Secure, Centralized Authentication with JumpCloud RADIUS
JumpCloud Cloud RADIUS helps secure your organization’s network and simplify the authentication process for everyone on your team. With only minimal in-house resources required, Cloud RADIUS automatically authenticates users to Wi-Fi, VPNs, switches, and other IoT devices.
Cloud RADIUS is fully integrated with our cloud directory, providing centralized management of credentials, access policies, and permissions. X.509 certificates are used to enable passwordless sign-on, MFA, and Zero Trust strategies. All of our RADIUS services are fully scalable.
Sign up today for a free trial to see how JumpCloud Cloud RADIUS gives you the power of RADIUS protocols without the need or expense of maintaining physical servers.
