Moving past the madness of manually updated X.509 certificates

Microsoft’s Active Directory (AD) is by far the most widely used enterprise repository for digital identities. Microsoft Active Directory Certificate Services (ADCS) is an integrated, optional component of Windows Server designed to issue digital certificates.

Since it’s a built-in and “free” option, it’s no surprise that ADCS has been widely embraced by enterprises around the world. An on-premises or cloud/hybrid public key infrastructure (PKI) has proven to be more secure and easier to use than passwords, and is far easier to deal with when automated certificate management is integrated into AD.

For organizations operating an AD environment, the ability to leverage the certificate template information already included in Microsoft certificate services can make running a Microsoft CA extremely appealing. Since AD and Microsoft certificate services are connected, you can seamlessly register and provision certificates to all domain-connected objects based on group policies. Auto enrollment and silent installation make certificate enrollment and renewal easy for IT administrators and end users alike.

One of the greatest advantages of the Microsoft CA is automation, but that advantage does not extend to endpoints outside the Windows environment. Unfortunately, there are no free or open source Linux, UNIX or Mac tools available today that provide auto-enrollment or integrate with the Microsoft CA. The only “free” option is to manually create and renew certificates from a Microsoft CA using complicated and error-prone commands.

Within enterprise networks, Linux is often used for critical services that require X.509 trusted certificates. One typical need is for an SSL/TLS Server Authentication certificate, or web server certificate, on Red Hat Enterprise Linux (RHEL), Ubuntu server, or other Linux distributions. Certificates are also often needed on many other endpoints, including macOS-based systems, and to provide trusted security for enterprise applications.

The traditional process of creating a X.509 certificate on Linux, UNIX or macOS manually requires a working level of PKI knowledge and can take three to six hours to complete. You have to generate a key pair, create a Certificate Signing Request (CSR), submit it to a Certificate Authority (CA), wait for a PKI administrator to issue a certificate, download the certificate, configure and update the application using the service, and finally verify that it’s active. An example of what’s involved in creating a CSR using Open SSL is shown in Figure 1.

Figure 1. Using OpenSSL to create a CSR requires knowledge of enterprise PKI policies for keys and certificates and filling in lots of details by hand.

A few years ago, when multi-year certificate lifespans were the norm and certificate volumes were lower, a few manually issued certificates weren’t seen as a big problem. When exceptions like a Linux or Mac system came up, they were handled on a one-off basis. This in turn led to the creation of manual processes. Such processes were easily justified by saying that the certificates could be easily tracked using a spreadsheet, and since the numbers were small and certificate renewals were years apart, it wasn’t worth the effort to get a product to solve the problem when the existing solution was sufficient.

Now, however, that has most definitely changed. Apple, Google and Mozilla have implemented policies that went to effect on Sept. 1, 2020 and that say that any new website certificate valid for more than 398 days will not be trusted by their respective browsers and instead will be rejected. Adding to the certificate management problem is the dramatic increase in the number of device and applications that require certificates, often numbering into the thousands or more.

Looking across the industry landscape, there are third-party certificate management systems (CMS) that can automate enterprise certificate processes more broadly, but such systems have require large-scale “rip and replace”. You have to deeply integrate each Linux system with Active Directory, including switching your system user authentication over as well.

This requires extensive changes to existing Linux and Microsoft infrastructure, staff re-training, and additional software licensing costs. The “rip and replace” approach also requires implementation time frames ranging from a few months to a few years for complex PKIs.

The advantage of such an approach – once you’ve worked through the implementation process – is end-to-end automation. When a CMS is used to create a certificate, it has all the data it needs to not only monitor the certificate for expiration but automatically provision a replacement certificate without human intervention.

While some CMS solutions can be incredibly complex, expensive, and time-consuming to install, there is a new generation of CMS offerings designed to simply extend the Microsoft-based PKI to encompass certificates on systems and applications outside the purview of Active Directory.

Such systems install into an existing Microsoft ADCS environment and mirror Windows certificate auto enrollment onto Linux, Unix or macOS systems. Certificates can be automatically created by registered computers from a central management console. Alternatively, as shown in Figure 2, the administrator of an end-node can request a certificate using one simple command without knowing how to create a keypair, generate a certificate request or know how to translate difficult to understand enrollment templates, formats and attribute requirements.

Figure 2. Creating a CSR is greatly simplified through automation and requires no PKI expertise.

Once issued, this command will automatically create a CSR, submit it to the enterprise Microsoft CA, and install the certificate after it has been issued. This is done using pre-configured PKI policies stored on the enterprise CA. The policies are set up based on the role or purpose of the certificate. Because these policies are pre-defined, the system admin doesn’t need to know anything beyond the role or purpose of the system they are setting up.

Once the certificate has been installed, the admin can move on to other tasks with the knowledge that the enterprise CA will automatically renew the certificate without further intervention. And because the certificate was created by the enterprise CA and not self-signed, the certificate is automatically verifiable by any application in the enterprise.

With the certificate lifetimes already getting shorter, and likely to continue getting shorter, the need for automated certificate management has never been greater. While the Microsoft CA addresses the automation challenge within the Active Directory environment, far too many enterprises are still relying on manual processes for non-Microsoft systems and applications. Rather than abandon the Microsoft CA at considerable expense and disruption, it may be time to consider a certificate management option that bring the benefits of ADCS to the entire enterprise.