Building a Subordinate Certification Authority server

We build Subordinate CAs not really for the purposes of redundancy, like with many other kinds of servers, but because there are specific tasks that you may want to perform 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, having 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 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 swing it. With Subordinate CA servers online, you have the option of bringing your Root CA offline, and using the Subordinates to issue all of 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 the previous recipe for more detailed information on the specific steps and settings with regards to installation of the role:

  1. Log in to our new server, which has already been joined to the domain.
  2. Follow the steps to add the Active Directory Certificate Services role to this server.
  3. When we implemented our Root CA server, we chose to install the web services as well. 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 definitely do if you planned on using an offline Root CA, but for our situation, we are not going to do this. We will stick with only Certification Authority in our list of available role services.

    How to do it…

  4. After the role has finished installing, go ahead and click on your link for Configure Active Directory Certificate Services on the destination server.
  5. Input credentials as needed and choose the only option we have in the list to configure, Certificate Authority.
  6. 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.

    How to do it…

  7. But 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 our purpose in this recipe.

    How to do it…

  8. 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.
  9. Choose your cryptography settings. These are typically going to be the same that you configured on the Root CA.
  10. Name your new Subordinate CA appropriately. If you have a specific function in mind for this CA, it will be helpful to you in the future to name it accordingly. For example, I intend to use this subordinate CA to issue all of the SSL certificates that I will need for internal webpages, so I have included SSL in the name.

    How to do it…

  11. 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.

    How to do it…

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

How it works…

Installing a Subordinate CA server in a network is very similar to implementing 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, we will do all of 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 division of the company to utilize.

See also

  • The Setting up the first Certification Authority server in a network recipe.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.224.65.20