The first hurdle to overcome when you want to start certificate work is putting the server into place. There are many valid questions to be answered. Do I need a dedicated server for this task? Can I co-locate this role on an existing server? Do I need to install an Enterprise or stand-alone CA? I've heard the term offline root, but what does that mean? Let's start with the basics and assume that you need to build the first CA server in your environment.
In an AD domain network, the most useful CA servers are of the Enterprise variety. Enterprise CA servers integrate with AD, making them visible to machines in the network and automatically trusted by computers that you join to your domain. There are differing opinions on the matter of best practices when setting up a series of CA servers. For example, there is a good test lab guide (referenced at the end of this recipe) published by Microsoft, which walks you through setting up a stand-alone Root CA, a Subordinate Enterprise CA, and then taking the stand-alone root offline. An advantage of this is that certificates are issued from the subordinate, not directly from the root, and so if certificate keys are somehow compromised in the environment, the Root CA is completely offline and unavailable so that it cannot be compromised. In this situation, you could wipe out the subordinate and the certificates it has published, bring up the offline root, build out a new subordinate, and be back in business publishing certificates without having to regenerate a new Root CA server.
Given the preceding best practice, or as defined by some anyway, it is surprising that I quite rarely see offline Root CAs in the field. Almost never, in fact. And in some of the cases where I have, the existence of an offline Root CA has caused problems. Just as an example, when deploying a DirectAccess infrastructure with one-time-password (OTP) capabilities in a customer environment, it was discovered that in order to make the OTP work correctly, the offline Root CA had to be brought back online. This wasn't in the best interests of the way the PKI had been established, and so instead we had to implement a second certificate environment to be a stand-alone root with two intermediaries in order to maintain an online Root CA for the purpose of the OTP certificates. This caused big delays in the project, as we had to build the three new servers necessary just to get the certificates published in the correct way, which caused a much more complex certificate infrastructure to support afterward.
If the preceding description confused you, good—because it's kind of a messy setup. If the company had instead been running on the online Root CA server in the first place, none of this extra work would have been necessary. I'm not advocating that an Enterprise Root CA that remains online all the time is the best way to do certificates, but it will cause you the fewest problems, and there are many companies that operate their production CA environments in exactly this way.
Another field observation is that most small- or medium-sized companies do not take the offline Root CA approach. In fact, I find that many small businesses need to co-host servers in order to save resources and have their CA role installed onto a server that is also performing some other task. Many times, the CA role is installed onto a Domain Controller. While at the surface level this appears to make sense, because the Enterprise CA services are so tightly integrated with AD, it is actually a bad idea. Microsoft recommends that you never co-host the CA role onto a Domain Controller, so stay away from that scenario if you can. That being said, I have seen dozens of companies that do exactly this and have never had a problem with it, so I suppose it's just your call on how closely you want to adhere to the Microsoft way. Make sure to do some reading from the links provided at the end of this recipe, as they should provide you with information that is helpful to make the right decisions about which certificate server setup is best suited for your network.
I have created a new Windows Server 2016 named CA1, a domain member upon which we will be enabling our new certificate infrastructure.
To install Active Directory Certificate Services onto your Server 2016, use the following set of instructions:
- Open Server Manager and click the Add roles and features link.
- Walk through the steps, choosing the default settings. When you come to the Server Roles screen, select Active Directory Certificate Services.
- Upon selecting the role, you will be prompted to confirm the installation of additional features. Go ahead and click on Add Features.
- Click Next a couple of times until you come to the Role Services screen. Here you will see a few different options that can be used on your CA server. Since we would like to be able to request certificates from a web interface on the CA, I am going to check the additional box for Certification Authority Web Enrollment. After selecting this box, you will receive an additional pop-up box asking you to add features. Make sure to allow those features to be installed.
- Click Next through the remaining screens until you reach the last page, where you click on the Install button to start the installation of the role.
- Once completed, you will see a link inside your installation summary screen that says Configure Active Directory Certificate Services on the destination server. You can click either on this link or on the Server Manager notifications yellow exclamation mark near the top of the Server Manager screen in order to continue configuring the CA role. On the first configuration screen, the wizard will probably auto-insert the username of the currently logged-in user. As stated in the text on that screen, make sure the user you are logged in as has Enterprise Admin rights on the domain, as we are planning to set this CA server up as an Enterprise Root CA.
- To get certificate services rolling on our server, go ahead and check the top two options to configure Certification Authority and Certification Authority Web Enrollment.
- Choose Enterprise CA.
- Choose Root CA; because this is our first CA server, we need to implement a root before we can think about a subordinate.
- Choose Create a new private key.
- On the Cryptography screen, you have the ability to choose the kind of crypto options you can provide on your CA server. Typically, the default options will work best if you're unsure of these settings. Just make sure that the Key length field is set to 2048 as a minimum. This is the new industry standard for the minimum key length. Similarly, hash standards have changed recently to SHA256, you should really no longer be using SHA1 for any of your certificates as it has now been estimated that SHA1 could be compromised in the next couple of years.
- If desired, you may modify the Common name for this CA. Keep in mind, this does not have to match the hostname of the server in any way. This is the name of the CA that will show up inside Active Directory as well as inside the certificates that you issue from this CA. Typically, I find that admins leave the Distinguished name suffix field alone.
- Change the Validity Period of your root certificate if desired. Often admins blow through this screen and leave it set at the default five years, but that means in just five short years you will suddenly invalidate every single certificate that you have ever issued from this CA server. I recommend increasing that number to 10 or even 20 years so you don't have to worry about this level of certificate expiry for a long time. The validity period will determine how often the root certificate has to be renewed.
- Continue through the remaining screens, leaving the default options set in place. When this wizard finishes, your CA server is now live.
- It is generally a good idea to schedule a reboot for this server after such a significant role installation. Go ahead and reboot when time permits.
In this recipe, we installed the first CA server into our network. As we discussed, you will want to make sure you read over some of the following links to help determine how many CAs you require and where they should be installed. This is one of those answers that can be different for every organization, and so I cannot make any blanket statements here that will apply for everyone. You may decide that your primary Root CA should be stand-alone rather than enterprise, and that is fine as long as it fits your needs. We also installed the web services piece of the role onto our primary CA because we plan to use this in upcoming recipes to issue certificates. If you are building an environment with multiple CA servers, you might determine that your root authority doesn't need the web interface…maybe only a particular subordinate CA will do that job for you. There are numerous ways that our design could play out, but through this recipe, I hope that enough information is provided so that you are comfortable with the actual process once those decisions have been made.
There are a couple of items that we did not cover in this recipe that should be pointed out. Following the preceding steps will get you a CA server up and running that is ready to issue certificates, there is no doubt about that. The remainder of the recipes in this chapter reflect CAs built exactly as shown here. However, there are additional steps that can be taken in order to further customize your CA settings if you have the need. If you plan to issue SSL certificate for websites, especially if you plan to install these certificates onto web servers which are facing the Internet, then you need to familiarize yourself with the Certificate Revocation List (CRL) settings. Whenever a certificate is accessed, the client computer checks in with the CRL in order to make sure the certificate is still valid. If the certificate is not valid or is fraudulent in some way, the CRL check will identify that compromise and disallow the connection. Particularly when publishing websites to the Internet that use certificates issued by your internal PKI, you will need to plan the publishing of your CRL so that external client computers can access it in a clean, secure fashion. Here is a great link to get you started on CRL information: http://technet.microsoft.com/en-us/library/cc771079.aspx.
The second piece of information I would like to reference is the CAPolicy.inf file. This is a file that can be populated with various customization settings for your CA server, such as the validity period of your root certificate, information about your CRL, and whether or not you want the default certificate templates to be loaded during CA role installation. If any of these settings are of interest to you, you simply create a CAPolicy.inf file with the appropriate configurations and place it inside C:Windows on your CA server prior to role installation. The role installation wizard will then utilize the settings inside this file during role installation and incorporate your customizations. If you do not use one of these files, it is fine, and the role will be installed with some default settings in place just like we did in this recipe. But if you are interested in changing some of them, check out this link for more detailed information on the CAPolicy.inf file: http://technet.microsoft.com/en-us/library/jj125373.aspx.
Neither of these items, tweaking the CRL or using a CAPolicy.inf file, are required in order to get a certificate environment up and running. Thus, they are not included in the step-by-step configuration of the recipe itself. But I am always a fan of having all knowledge available to me on a particular subject, and so I strongly encourage you to read over these additional links provided to round out your understanding of possible functionality.
Here are some links that make for good additional reading on this subject. In order to make an informed decision about what sequence of CA servers is right for your environment, I encourage you to do as much reading on the subject as possible before proceeding in the production network: