Building a subordinate Certification Authority server

Subordinate CAs aren't built for redundancy, just like many other kinds of servers. They are meant for performing specific tasks that you may want to process on a subordinate CA rather than a root CA. If you issue a lot of certificates or different kinds of certificates, you may want to differentiate between CA servers when issuing. Perhaps you want machine certificates that are used for IPsec to be issued from IPSEC-CA, but the SSL website certificates that you issue should show as being issued from WEB-CA. Rather than building out two independent root CAs that both have top-level rights, you should consider creating a single root CA, maybe called ROOT-CA, and placing these two CA servers in a subordinate role under the root CA in the chain. This can also be useful for geographically dispersed networks that have subordinate CA servers dedicated to assigning certificates for different offices or regions.

As we discussed in the previous recipe, there are certainly some best practice standards that would suggest you should only utilize subordinate CAs to accomplish your certificate issuance. I don't always find that this is feasible for companies, particularly smaller ones, but it is a good idea if you can. With subordinate CA servers online, you have the option of taking your root CA offline and using the subordinates to issue all your certificates.

Getting ready

We are inside a domain network and have a single Enterprise root CA online and running. We now require an additional server that will be joined to the CA environment as a new subordinate CA.

How to do it…

To implement our new subordinate CA server, the process will be very similar to the Setting up the first Certification Authority server in a network recipe. However, there are a few key differences, and that is where we will focus. Some of the specific steps may be shortened here; please refer to the previous recipe for more detailed information on the specific steps and settings with regards to installing the role:

1. Make sure our subordinate CA has been added to Server Manager on our Windows 10 machine and then follow the steps provided to add the Active Directory Certificate Services role to this server.
2. When we implemented our root CA server, we chose to install the necessary web services. This will enable us to request and issue certificates from a browser inside our network. You have the option of installing these web services on the new subordinate CA, which you would do if you planned on using an offline root CA. For our situation, we are not going to do this. We will stick with only Certification Authority in our list of available role services:
   

   Figure 4.7 – Only selecting the Certification Authority role

3. After the role has finished installing, go ahead and click on your link for Configure Active Directory Certificate Services on the destination server.
4. Input the credentials as needed and choose the only option we have in the list to configure, Certificate Authority.
5. Here is where we start to detour from the path that we took with our root CA creation. We are still choosing to set up an Enterprise CA because we still want it to be domain integrated.
6. However, instead of choosing to install a new root CA, we are going to choose the option for Subordinate CA. In fact, it was already chosen for us as the default because it recognizes that a root CA already exists in the network. We could install another root CA, but that is not the purpose of this recipe:
   

   Figure 4.8 – Selecting a subordinate CA this time

7. Choose Create a new private key. The only time we would typically want to use an existing private key is when rebuilding a CA server.
8. Choose your cryptography settings. These are typically going to be the same as the ones you configured on the root CA.
9. Name your new subordinate CA appropriately. If you have a specific function in mind for this CA, it will be helpful to you to, in the future, name it accordingly. For example, I intend to use this subordinate CA to issue all the SSL certificates that I will need for internal web pages, so I have included Web in the name:
   

   Figure 4.9 – As in the previous CA, give your CA a better name than default

10. Now, we come to a new screen. We need to acquire a certificate from our parent CA server in order to issue certificates from this new one. Choose the option for Send a certificate request to a parent CA and use the Select… button to choose your root CA:
    

    Figure 4.10 – Selecting the root CA to receive our subordinate CA certificate from

11. On the following screen, adjust the location of the certificate database files if required; otherwise, click Next and then Configure.

How it works…

Installing a subordinate CA server in a network is very similar to when we implemented our first root CA server. In our case, we simplified the installation by not having the requirement for the web services to run on the subordinate as we will do all those requests from the root CA.

We now have a root CA running and a subordinate CA running under it. For our installation, we are going to leave both online and running as we intend to issue certificates from both. We could easily run through this same process again with another new server in order to create another subordinate CA, maybe to issue a different kind of certificate or for a different pision of the company to utilize.

See also

• The Setting up the first Certification Authority server in a network recipe