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, but 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 an 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 are to have them use a cross-over cable between the CA and the HSM. If there are 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 aren’t needed. So off goes everything except Internet Protocol Version 4 (TCP/IPv4).
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 a 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 the 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 the security. How big of a risk? That is up to you and your organization. But you will be increasing 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 airgap. 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 setup 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 week 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 comes 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, short list of recommendations. Some of these are obvious when you look at them, a few are not.