When considering the failures of credential-based authentication, it’s no surprise that many security-conscious organizations have been upgrading to certificates for authentication. One of the benefits of certificates is the flexibility they provide, including how to acquire certificates, how to distribute them, and how to manage them over time.
After considering all their options, many organizations have opted for a private Internal Certificate Authority (CA) to maximize management capabilities and utilize certificates to their fullest potential for network authentication.
What Is an Internal CA?
An Internal CA works like any other certificate authority – it hosts certificates to be distributed to servers, users, devices, etc. The difference between a private Internal CA and a public CA is that an Internal CA is not publicly trusted and cannot be used outside an organization’s infrastructure.
When an organization uses certificates from a public CA, those certificates are managed by a 3rd party and severely limit how much of the certificate can be customized to fit specific needs. Additionally, organizations are often charged on a per certificate basis, so a large enterprise with thousands of devices would merit a hefty price tag. With an Internal CA, certificate management capabilities are unleashed and there is no limit to how your organization operates with certificates.
Managing Network Access with an Internal CA
One of the most important functions of managing an Internal Certificate Authority is controlling who has certificates and access to the network. If you’re unable to control who has network access, the benefits of certificates go out the window and there will be a significant risk of a data breach. Below are some of the basics of certificate management tools.
Certificate Revocation List (CRL)
At its core, a CRL is a list of certificates that have been revoked from users so they no longer have network access. This situation would occur when someone no longer needs access, such as leaving a company or graduating from a university.
If a user with a revoked certificate attempts to authenticate, the RADIUS server checks their certificate against the CRL. If the certificate has been revoked, access will not be granted, and the network stays protected from unauthorized access.
There are usually two different CRLs at work, the Delta CRL and the Base CRL. The difference between them is the frequency at which they are updated. The Delta CRL is updated more frequently, often an interval such as a week or a month, and contains every certificate revoked within that update period. The Base CRL contains every revoked certificate and is updated with the Delta CRL’s certificates at each update interval. This staggered approach affords speed of authentication benefits to the organization.
Online Certificate Status Protocol (OCSP)
An organization using OCSP separates revoked certificates when the user sends their certificate for authentication. When this occurs, an OCSP request is sent to the OCSP Responder, which will check the CA for that particular certificate. Based on the certificate’s status, it will respond with an answer of good, revoked, or unknown.
While both options are valid, a CRL is superior to OCSP for more security-focused operations. OCSP has no encryption requirement during the certificate check because it is communicating with the CA. Of course, lack of encryption opens up opportunities for a Man-in-the-Middle attack on the organization. A CRL communicates with the PKI (Public Key Infrastructure) during the certificate check, so the information is sent over-the-air in an encrypted format.
Additionally, an OCSP is vulnerable to Replay Attacks. Because the information sent over-the-air is unencrypted, an attacker can intercept a certificate’s “good” response and replay it later in place of a “revoked” response. This would allow an attacker to use a revoked certificate to authenticate to the network and cause enormous amounts of damage to the organization and its resources.
A Well Configured RADIUS Server
The most important tool for managing network access with certificates is the RADIUS server. The basic operation of a RADIUS is to ensure only approved users with a valid certificate are able to gain network access. For certificate-based authentication, it’s recommended to use the EAP-TLS authentication method to prevent outside attacks and enable rapid and accurate authentication.
Of course, there are countless RADIUS vendors and their capabilities range greatly, but they all serve the basic function of managing access. For some, this is as far as it goes. Others take a more proactive approach to managing certificates.
SecureW2’s Dynamic Cloud RADIUS improves certificate management by allowing the RADIUS to communicate directly with the IDP during authentication. This is useful in a situation where a user needs a certificate replaced but you don’t want an interruption in service. Because certificates contain so much information pertaining to the user, the certificate may need to be updated during their tenure with the organization. But certificates are static, so what’s the solution?
With Dynamic Cloud RADIUS, a network admin can simply update their information in the IDP. When the user authenticates with their original certificate, the RADIUS can confirm their identity but apply any updated policies and access settings that have been updated in the IDP. The authentication process is unchanged for the user, and it ultimately saves time and effort for both the user and admin.
Managing Certificates Over Time
The most important part of managing internal certificates is how to maintain them effectively over a long period of time. If you let certificates get out of hand or overwhelm your IT department, the network will be at a huge risk of breach. SecureW2 is not only the key to distributing certificates efficiently, they’re also on your side to facilitate certificate management.
The most powerful tool is our management portal, which affords admins a huge amount of control over their network and all certificates. Admins can limit the number of certificates per user to prevent someone from acquiring certificates for a huge number of devices and potentially losing them or giving them away. Additionally, the length of a certificate’s life is fully in control of the organization, unlike many public CAs. Network admins can set certificates to expire in 1 year, 20 years, or anything in between.
Perhaps most importantly is the customization of access and group policies that are applied to different users via certificates. Based on a user’s standing in an organization, they can be distributed highly specific certificate settings without manual configuration of each individual. In the case of a university, professors may need 1 year certificates with access to resources A, B, and C, while students need 4 year certificates with access to resources D, E, and F. Simply configure those settings once for a student group policy and professor group policy and those settings will be applied to every professor or student who is distributed a certificate.
Certificate Management Should Be Efficient
Certificates are known for creating an efficient authentication experience for users; the certificate management experience should be similar for admins. With a private Internal CA from SecureW2, the amount of control given to admins allows them to create a set-n-forget certificate network. Once the network is configured for certificates, the amount of hands-on work that needs to be done to manage certificates is minimal, especially compared to credential-based networks. Check out our pricing page to see if SecureW2’s certificate solutions can be the efficiency your network needs.
