In-Depth

Securing Windows Enterprise CAs

Best practices in securing your enterprise Windows Server-based certificate authority to ensure all resources are trusted.

• By Brien Posey
• 03/01/2016

When it comes to certificate use in the enterprise, there are two main schools of thought. The major­ity of large organizations purchase certificates from well-known certificate authorities (CAs). In all honesty, this is probably the best method for acquiring certificates because the commercial certificates are trusted by de-fault by most OSes. The other common method involves the creation of self-signed certificates.

The latter aren't quite suitable for use in production environments because they're not authoritative. In other words, a self-signed certificate really can't be used as proof of identity, because anybody can generate a self-signed certificate. As such, self-signed certificates are completely untrusted by network devices (as they should be). Microsoft's stance on self-signed certificate use has long stated that using self-signed certificates is better than nothing, but you should be using "real" certificates in production environments.

Aside from these two main methods, there's another option. Windows Server has long offered the ability to build your own enterprise CA. A homegrown enterprise CA can be considered an "in between" solution. A well-known commercial CA issues certificates that are almost universally trusted. Conversely, certificates issued by a do-it-yourself enterprise CA are initially untrusted. It's your responsibility to configure devices to trust those certificates. Hence, enterprise CAs work well for use on an organization's own internal network, but they're not appropriate for employee-owned devices.

Some have made the case that the certificates issued by an enterprise CA are really just another type of self-signed certificate. Although there's some small measure of truth to that, there are actually substantial differences between self-signed certificates and the certificates issued by an enterprise CA.

A self-signed certificate is generally suitable only for use on the machine that generated the certificate. An en-terprise CA can issue a certificate to itself, but it's also able to create certificates for other devices. Hence, an en-terprise CA is an infrastructure component for issuing certificates throughout your organization. In fact, the in-frastructure components and methodologies used by an enterprise CA are very similar to those used by a commercial CA. However, when you create an enterprise CA, your organization maintains ownership of all of the certificate-related services. Enterprises don't typically issue certificates to external customers from their CAs, although it can be done.

A commercial CA is just that -- commercial. Its entire business model is based around trust. Customers who purchase certificates from a commercial CA must have confidence that the CA is going to maintain strict secu-rity and prevent any sort of breach that would undermine the integrity of the certificates. As such, a commer-cial CA goes to great lengths to harden its servers against attack. Because a Windows enterprise CA is basically a scaled-down version of what commercial providers use, it makes a lot of sense to make a concerted effort to harden your organization's CA. After all, if your CA is ever compromised, then certificate-based encryption and identity management within your organization can no longer be trusted.

In many ways, hardening an enterprise CA is like hardening any other server in your organization. Microsoft has long provided best-practices guidance for maintaining Windows Server security. These best practices should be followed as closely as possible. Given the sensitive nature of enterprise CAs, however, there are some additional considerations.

Physical or Virtual Hardware?
One of the first considerations is whether your enterprise CA servers should run on physical or virtual hard-ware. Some have suggested it's best to use dedicated physical hardware for running an enterprise CA -- or at least for use by the root CA. The thinking behind this recommendation is that by using a dedicated physical server, you can reduce the potential attack surface by stripping away the entire virtualization layer or by phys-ically removing the server from the network.

While I do understand the reasoning behind this recommendation, I'm not convinced that using dedicated physical hardware is always necessary for every CA. If you're using a hierarchy of enterprise CAs, then I rec-ommend using a dedicated physical server for the Root CA. But it's up to you to decide whether dedicated hardware is appropriate for subordinate CAs.

The Root Certificate Authority
When you initially configure an enterprise CA, Windows asks you if you'd like to create a Root CA or a Subor-dinate CA (see Figure 1). A Root CA is a top-level enterprise CA. If you only deploy a single enterprise CA server then that server is the Root CA. If, however, you create multiple enterprise CAs (for the purpose of scalability or disaster prevention), then the Root CA will be the server that resides at the top of the hierarchy. Other CA servers act as subordinates to the Root CA.

If your environment uses a Root CA and one or more subordinate CAs, then there's an entire laundry list of best practices related to securing the Root CA. The reason for this is your Root CA is the most important of all your CAs. If the Root CA is ever compromised, then all subordinate CAs are considered to be compromised, as are all of the certificates the servers have collectively issued. As such, keeping the Root CA secure is of the utmost importance.

Microsoft has already taken some steps to protect CAs. For example, in Windows Server 2012 and higher certificate requests are required to be encrypted. This encryption was an option in previous versions of Windows, but Windows Server 2012 was the first version to require it. Another thing Microsoft has done is to make it possible to operate the Certificate Services on Server Core.

Despite Microsoft's secure-by-default approach to CA configuration, there are other steps you can and should take. For organizations with a Root CA and one or more Subordinate CAs, for example, Microsoft recommends you physically remove the Root CA from your network. By completely unplugging this server (and storing it in a secure vault), you can prevent it from being compromised. Subordinate CAs can handle the task of servicing certificate requests.

Some organizations even go so far as to use a Hardware Security Module (HSM) to store CA keys at the hardware level. Most HSMs are PCI-based, but similar functionality can be achieved through USB devices or network appliances.

This brings up another important point: Unless your Root CA is the only certificate authority on your network, you should never issue certificates directly from the Root CA. The Root CA should remain powered down and disconnected from the network unless you have a compelling reason to bring it online.

It's also a good idea to upgrade your enterprise CAs to the latest Windows Server OS (if necessary). With the release of Windows Server 2012 R2, Microsoft introduced a number of new features and capabilities related to the Certificate Services. These new features and capabilities include things like support for internationalized domain names, support for certificate renewal with the same key and support for Windows PowerShell.

Database and Log File Placement
A Windows-based CA makes use of a database that resides on the CA server. This database, like many other Mi-crosoft databases, consists of the database itself and a series of transaction logs. Microsoft strongly recommends placing the database and the transaction logs on separate disks. There are two reasons for this. First, using sep-arate disks for the database and the transaction logs helps to improve performance. In fact, Microsoft recom-mends placing the transaction logs onto a striped volume, or a similar high-performance storage device.

The other reason for keeping the database and the transaction logs separate from one another is that it makes disaster recovery easier. If, for example, the volume containing the database were to fail, the transaction logs would still exist because they reside on a separate disk. The transaction logs can be used to recover da-tabase transactions that have occurred since the last backup.

When you initially configure a Windows enterprise CA, the configuration wizard prompts you to enter a path to use for the database and the transaction logs. Windows attempts to store the database and the trans-action logs in the same location by default (see Figure 2).

If you go with the default paths, but later decide you want to relocate the database or the transaction logs, you can do so by delving into the file system and the Windows registry. The procedure for relocating the da-tabase and transaction logs is relatively simple, but you must always exercise care when editing the registry because making a mistake within the Registry Editor can destroy Windows. I recommend making a full system backup prior to attempting a database or transaction log move. Consequently, the first thing you should do is stop the Certificate Services service. Next, open File Explorer and navigate to %SystemRoot%\System32\CertLog. This is the default database and transaction log location. Next, move the components to the desired location. Remember, the database and transaction logs should ideally reside on separate disks. Open the Registry Editor and update the registry to reflect the new paths being used. The registry entries (see Figure 3) of interest include:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DBDirectory 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DBLogDirectory 
KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DBSystemDirectory 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\DBTempDirectory

After updating the registry, start the Certificate Services service. After doing so, be sure to check the Application event log to make sure you didn't introduce any problems by moving the files.

Review Your Backup Procedures
As with any other important data, it's extremely important to back up the Certificate Services on a regular basis and test the backups. The Windows Server 2012 R2 version of Windows Server Backup includes the certificate database components in a System State backup. If you're using a third-party backup application, you'll need to check with the vendor to see how the Certificate Services are protected.

Your enterprise CA can also be backed up through Windows PowerShell by using the Backup-CARoleService cmdlet. Backups can be restored by using the Restore-CARoleService cmdlet.

As you can see, there are a number of different things that can be done to improve the security of a Win-dows-based enterprise CA. If your organization issues its own certificates, then your CAs are among the most sensitive servers on your network and should be treated as such.