Setting up the first Certification Authority server in a network_Windows Server 2019 Cookbook-QQ阅读男生都市网

上QQ阅读APP看书，第一时间看更新

Setting up the first Certification Authority server in a network

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 standalone 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) that have been published by Microsoft that walks you through setting up a standalone Root CA, a subordinate Enterprise CA, and then taking the standalone root offline.

An advantage of this is that certificates are issued from the subordinate, not directly from the root. 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 . Then, you can 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. Due to this, we had to implement a second certificate environment as a standalone root with two intermediaries. This enabled us 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 three new servers just to get the certificates published in the correct way. This created a more complex certificate infrastructure to support afterward.

If the preceding description confused you, good – 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. However, it will cause you the fewest problems. In fact, many companies 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. This includes them having their CA role installed onto a server that is also performing some other task. Many times, the CA role is installed on a Domain Controller. While at the surface level this appears to make sense, because the Enterprise CA services are so tightly integrated with AD, this is actually a bad idea. Microsoft recommends that you never co-host the CA role on 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 that you do some reading by taking a look at the links provided at the end of this recipe, as they should provide you with information that will help you make the right decisions about which certificate server setup is best suited for your network.

Getting ready

I have created a new Windows Server 2019 named CA01. We are going to do all our configuration from a Windows 10 computer with all the RSAT tools installed so that we can use some of the skills we learned in previous chapters for remote management. If you want to, you can create your CA as a Windows Server Core (more on this in Chapter 12, Server Core).

How to do it…

To install Active Directory Certificate Services onto your server, use the following set of instructions:

On your Windows 10 machine with RSAT installed, open Server Manager. Make sure your new CA server is in your server list and click the Add roles and features link.
Walk through the steps provided, choosing the default settings. When you come to the Select Destination Server screen, make sure you choose your CA server:

Figure 4.1 – The Select destination server screen and selecting the CA server
On the Server Roles screen, select Active Directory Certificate Services.
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 you allow those features to be installed:

Figure 4.2 – Selecting the Certification Authority Web Enrollment role
Click Next through the remaining screens until you reach the last page, where you need to click on the Install button to start installing 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 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 may auto-insert the username of the currently logged-in user. If it doesn't, click Change and enter your credentials. 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.
Tip
You can click on More about AD CS Server Roles at any time to read more information about the different types of CA roles and features available. For the purposes of this recipe, we will not discuss them all, but rather focus on creating our Enterprise root CA.
To get certificate services rolling on our server, go ahead and check the top two options used to configure Certification Authority and Certification Authority Web Enrollment:

Figure 4.3 – Selecting the roles to configure for the CA server
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 can choose the kind of cryptography options you will 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 industry standard for the minimum key length. Similarly, hash standards have changed recently to SHA256, so you should no longer be using SHA1 for any of your certificates:

Figure 4.4 – CA cryptography options for the new private key
If desired, you may modify the Common name for this CA option. Keep in mind that this does not have to match the hostname of the server in any way and that it can never be changed. It is usually a good idea to not use the server name in this field as you may move the CA role to a different server many years down the line and then have a mismatched certificate/server name. This name 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:

Figure 4.5 – The CA common name has been changed to a more generic name
Change the Validity Period section of your root certificate if desired. Often, admins blow through this screen and leave it set at the default 5 years, but that means in just 5 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 that you don't have to worry about this level of certificate expiry for a long time. This validity period will determine how often the root certificate must be renewed.
Tip
A certificate can never be issued with an expiry that is past the root certificate expiration date. This means that if you have a 5-year expiration on your CA and issue certificates with a 2-year validity, you will be rotating your root CA every 3 years – all the more reason to make it longer.
Continue through the remaining screens, leaving the default options set in place. When the wizard has finished, your CA server will be live:

Figure 4.6 – A successful AD CA configuration

That was a fairly complex process, and not one that you're going to repeat very often. Because of this, you may not want to bother going through this process via PowerShell as the GUI is honestly no more difficult. However, the relevant documentation, should you wish to explore this is, can be found in the See also section of this recipe.

How it works…

In this recipe, we installed our first CA server in 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, so I cannot make any blanket statements here that will apply for everyone.

You may decide that your primary root CA should be standalone rather than Enterprise, and that is fine if it fits your needs. We also installed the web services piece of the role onto our root 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 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 has been 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. The remainder of the recipes in this chapter reflect CAs that have been built in the same way they've been built 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 on web servers that are facing the internet, you need to familiarize yourself with the Certificate Revocation List (CRL).

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 when to publish your CRL so that external client computers can access it in a clean, secure fashion. Here is a great link to get you started with CRL: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc771079(v=ws.11).

There's more…

The CAPolicy.inf file can be populated with various customization settings for your CA server. These include the following:

The validity period of your root certificate
Information about your CRL
Whether you want the default certificate templates to be loaded during CA role installation

If any of these settings are of interest to you, do the following:

Simply create a CAPolicy.inf file with the appropriate configurations.
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, that is fine; 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: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj125373(v=ws.11).

Neither of these options, that is, 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 on a particular subject, so I strongly encourage you to read over the additional links that have been provided so that you round out your understanding of possible functionality.