This month, we’ve been talking about digital certificates and public key infrastructure (PKI). So far we’ve covered the basics of how certs work, and how to install publicly trusted certs for Exchange and IIS. This week, we’re going to tackle what’s involved in setting up your own PKI using Microsoft Active Directory Certificate Services (AD CS).
As the name suggests, AD CS is highly dependent on Active Directory. So if you’re already running AD DS in your environment, then setting up a PKI server can be as easy as installing a few extra roles. But there are a few other things to take into consideration before diving in to it.
Do I Need My Own PKI?
Like any new service, it’s a good idea to consider whether the advantages of a PKI will outwegh the costs. With your own PKI, you can issue certificates for a number of internal or external services without needing to pay a per-certificate fee. You can use SSL to secure internal Web sites and services, or external services that are accessed only by trusted devices. Additionally, you can issue client certificates for services like NPS/RADIUS, VPN, Exchange ActiveSync, and OWA, giving you an added level of security.
However, PKI isn’t completely free. There is the licensing cost associated with running additional Windows servers, plus the overhead of maintaining these servers. You’ll need to weigh these costs against the benefits that you’ll get from a PKI.
Components of a PKI
At its simplest, a PKI can consist of a single server with the AD CS role installed. However, if you’re planning on using it in production, it’s best to separate out the roles for better security and manageability.
A two-tiered PKI consists of an offline Root Certificate Authority, and one or more online Issuing CAs. The Root CA signs the certificates for the Issuing CAs, which all of your devices and users must trust, and thus its private key has the greatest amount of power. However, creating new issuing CAs should be an infrequent event. For these reasons, the root CA is usually stored offline, separated from the network, and inaccessible to hackers.
The Issuing CA is the CA that signs and issues certificates for individual users and devices. It is available on your internal network for users and devices to request certificates (and automatically deliver them, if you choose).
So we’re up to two servers so far. But there is also the matter of where to store the root certificate, intermediate certificates, and the Certificate Revocation List (CRL). If all of the clients using your certificates will be internal to your network, then these things can be stored automatically in AD, where the clients can find them via LDAP. But if you’ll be using your PKI to secure external services, these things will need to be hosted on an external-facing web server.
Other Design Decisions
Before you’re ready to build a PKI, there are some other questions that need to be answered. First, what key length will you use? The longer the key length, the more secure it is, but certain applications have a maximum key length that they will support. 4096 bit keys are the standard now, but some applications may require a maximum 2048-bit key.
Second, your root CA certificate, intermediate CAs, and individual certificates must have a validity period. Generally, the root CA has a very long validity period - up to 20 years, while the intermediate CA’s will have a shorter period. Individual certificates will have a shorter period still -- months to a few years, depending on your security requirements.
Finally, there are security considerations to take into account. The CAs themselves need to be physically and virtually secure -- if a CA’s private key is compromised, then all certificates issued by it must be invalidated and replaced. So take this into account straight from the design phase.
Once you’ve planned out what you need out of your PKI, it’s time to start building it. Our next few Tech Thursday articles will cover how to set up a simple Microsoft Certificate Services PKI. Stay tuned!
E-N Computers is an IT service provider helping businesses in Virginia, Maryland, and Washington D.C. keep their networks secure and their data safe. Contact us today to find out how we can help protect your network from today’s complex threats.