Offline Certificate Authority – What Exactly Does that Mean?

This post started as recommended maintenance and updates for offline CAs, and it became clear I should make this a two-part post. So today I am covering what an Offline CA really means, and tomorrow I will cover recommendations for maintaining one of them.

First, we must cover what I mean by Offline CA – believe it or not, this terminology has been interpreted in interesting ways over the years. An offline CA in the purest sense is one with NO network connection. Often times I see this as implemented as a CA that is turned OFF when not in use. Since the Root and Policy are only accessed once or twice a year, the customer reasons there is no network connection. However, when the CA is powered on, it is accessible on the network. This is generally done to make the CA administrator’s job a little easier as they can copy files onto and off of the CA. However, it also means the CA is exposed to the network and all the nasty things that could affect the CA. The case is argued that the risk is minimal since the machine is on the network for such a small period of time. But I will tell you that I have found a CA accidentally left on after maintenance and as a result, it was sitting on the network unprotected for a year! Much better to make sure the CA will never see the light of the day.

Now, some exceptions need to be made for CAs connecting to a Hardware Security Module – such as a Thales nCipher Connect, which is connected via CAT5 cable. Note that I did not say connected via the production network. My preference for the Root and Policy CA is to have them use a cross-over cable between the CA and the HSM. If there is more than one CAs that need to access the HSM, I will recommend buying a cheap $9.99 Bestbuy hub and connecting the CAs and the HSM on a dedicated, darknet connection.

In addition, all connections going to an HSM should be stripped down. So the network interface should have all of the non-essentials removed from the Network interface. There is a rash of items installed by default on the network adapter that isn’t needed. So off goes everything except Internet Protocol Version 4 (TCP/IPv4).

Before

After

The IP network is then configured only with an IP address and subnet mask. It will never need a default gateway or DNS server configured. If you find yourself needing to define those things to get your CA to talk with your HSM, you might be on a network that is vulnerable.
I also recommend ensuring the CAT5 cables going to these CAs are securely connected from the CA to the HSM. It’s not unheard of to see a cable get accidentally plugged into a production network “because that cable just didn’t look like it was going to the right place”. So to secure these cables, you can use an RJ45 lock like one of these: http://store.cableorganizer.com/p-55861-standard-lock-in-device-ten-devices-orange-and-one-tool-black.aspx. This will ensure the cable between the CA and the HSM remains securely in place.

If your CAs are virtual machines, you have some larger challenges. Frankly, there is no such thing as a true offline CA when using VMs. The majority of the time, the “offline” (note the air quotes here) CA is on a shared VM host running other machines. By its very nature, the VM host is on the network. The CA guest VM can be configured to have no connection to the network, but I can connect to the VM host remotely and then access the “offline” CA. So, a virtual environment is a compromise to security. How big of a risk? That is up to you and your organization. But you will not increase security by using a VM.

Another VM issue is how you will transfer files on and off of the “offline” CAs. During maintenance periods and CRL publishing, you will need to get files in and out of the CA instance. VMWare makes this a bit difficult as you can’t simply pass through a USB flash drive and there are no native tools for creating virtual floppies. So you will need to find a 3rd party tool and develop the process to create the floppy, connect it to the VM, copy the files and then mount the floppy on another computer to remove the files. Alternatively, you can create virtual hard disks and mount it in the guest VM. Either way, it takes time and effort to maintain this air gap. It’s also the number one reason people inevitably connect their VMs to the network to perform maintenance and publishing activities and thus negate the point of the offline CA.

Lastly, it should go without saying, these offline CAs should NEVER join an Active Directory. You would think this would be obvious as if they shouldn’t be on the network, they shouldn’t be able to join AD. But over the years I have seen some interesting scenarios. One set up the CA on the network, joined it to AD, and then installed Certificate Services. They then very cleverly found a way to remove it from the domain and then isolated it from the network. Microsoft has many controls to prevent domain membership changes – but they found a weak spot. Lastly, Offline Domain join, while technically possible, serves no purpose for these CAs either.

In my next post, I will cover one of the most common questions that come up when designing and deploying a PKI with CAs that are offline is “how do we patch and manage the CA?”. An excellent question and one that I have a fairly standard, shortlist of recommendations. Some of these are obvious when you look at them, a few are not.