Windows Server 2019 – Planning your PKI

How to Change the server name on Windows Server 2019

Since we are revolving all of our discussion in this book around Windows Server 2019, this means that your CA server can and should be one provided by this latest and greatest of operating systems. As with most capabilities in Server 2019, the creation of a certification authority server in your network is as simple as installing a Windows role. When you go to add the role to a new server, it is the very first role in the Active Directory Certificate Services (AD CS) list. When installing this role, you will be presented with a couple of important options and you must understand the meaning behind them before you create a solid PKI environment.

Your server’s hostname and domain status cannot be changed after implementing the CA role. Make sure you have set your final hostname, and joined this server to the domain (if applicable), prior to installing the AD CS role. You won’t be able to change those settings later!

Role services

The first decision you need to make when installing the AD CS role is which role services you would like to install, as you can see in the following screenshot:

Clicking on each option will give you a description of its capabilities, so you can probably determine which pieces of the role that you need by poking around on this screen. Here also is a short summary of these options. Note that I am listing them out of order, because of the way that I typically see them configured in the field:

  • Certification Authority: This is the primary certificate engine that needs to be installed in order for this server to officially become a CA.
  • Certification Authority Web Enrollment: Often, this one gets installed as well, especially in environments that are small enough to be running a single CA server for the entire environment. The web-enrollment portion will install IIS (web server) capabilities on this server, and launch a small website that is used for the purposes of requesting certificates. We will discuss this further when we walk through issuing certificates from this web interface, later in the chapter.
  • Certificate Enrollment Web Service and Certificate Enrollment Policy Web Service: Most of the time, we are only concerned with issuing certificates to our company-owned, domain-joined systems. In those cases, these two selections are not necessary. If you plan to issue certificates to non-domain-joined computers from this CA server, you want to select these options.
  • Network Device Enrollment Service: As the name implies, this piece of the CA role provides the capability to issue certificates to routers and other kinds of networking devices.
  • Online Responder: This is a special function reserved for larger environments. Inside every certificate is a specification for a Certificate Revocation List (CRL). When a client computer utilizes a certificate, it reaches out and checks against this CRL in order to make sure that its certificate has not been revoked. The CRL is an important piece of the certificate security puzzle; in an environment with thousands of clients, your CRL may be very, very busy responding to all of these requests. You can deploy additional CA servers that are running Online Responder to help ease that load.

For the purposes of our lab, and to cover the required capabilities of most small-to-medium businesses out there, I am going to select the two options shown in the earlier screenshot:  Certification Authority and Certification Authority Web Enrollment.

Enterprise versus Standalone

Following the installation of your AD CS role, Server Manager will notify you that certificate services needs some additional configuration, as is common with many role installations. When configuring your CA role for the first time, you will be presented with a big choice. Do you want this CA server to be an Enterprise CA or a Standalone CA?

Let’s start with the enterprise CA. As the wizard will tell you, an enterprise CA server must be a member of your domain, and these certificate servers typically stay online so that they can issue certificates to computers and users who need them. Wait a minute! Why in the world would we want to turn a certificate server off anyway? We will discuss that in a minute, but if you intend to utilize this CA to issue certificates, it must obviously remain turned on. Most CA servers within a domain environment will be enterprise CAs. When creating an enterprise CA, your templates and some certificate-specific information is able to store itself within Active Directory, which makes integration between certificates and the domain tighter and more beneficial. If this is your first interaction with the CA role, I recommend you start with an enterprise CA because this better meets the needs of most organizations.

As you can correctly infer from the preceding text, this means that a standalone CA is less common to see in the wild. Standalones can be members of the domain, or they can remain out of that part of the network and reside on a local workgroup. If you had a security requirement that dictated that your certificate server could not be domain-joined, that might be a reason you would use a standalone CA. Another reason might be because Active Directory simply does not exist in the chosen environment. In my eyes, it would be extremely rare to find a network where someone was trying to use Windows Server 2019 as their certification authority and at the same time was not running Active Directory Domain Services, but I’m sure there is a corner case somewhere that is doing exactly this. In that case, you would also need to choose standalone. A third example when you would choose standalone is the event we alluded to already, where you might have a reason to turn off your server. When you run this scenario, it is typically referred to as having an offline root. We haven’t talked about root CAs yet, but we will in a minute. When you run an offline root, you create the top level of your PKI hierarchy as a standalone root CA, and then you build subordinate CAs underneath it. Your subordinate CAs are the ones doing the grunt work issuing certificates—which means that the root can be safely shut down since it doesn’t have any ongoing duties. Why would you want to do this? Well, most companies don’t, but I have worked with some that have very high-level security policies, and this is why you might visit this topic. If all of a company’s CA servers are tied together as enterprise CAs with all of their information being stored inside Active Directory, a compromise to one of the subordinate issuing CAs could spell disaster for your entire PKI. It is possible that the only way to remediate an attack, would be to wipe out the whole PKI environment, all of the CA servers, and build them up again. If you had to do this, it would mean not only rebuilding your servers, but also re-issuing brand new copies of all your certificates to every user and device that has them.

On the other hand, if you were running a standalone root CA that was offline, it would not have been affected by the attack. In this case, you could tear down your affected certificate servers, but your core root server would have been safely hidden. You could then bring this root back online, rebuild new subordinates from it, and have an easier path to being 100% operational because your root keys that are stored within the CA would not have to be re-issued, as they never would have been compromised in the attack.

Like I said, I do not see this very often in the field, but it is a possibility. If you are interested in learning more about offline root CAs and their uses, I highly recommend checking out the TechNet article at http://social.technet.microsoft.com/wiki/contents/articles/2900.offline-root-certification-authority-ca.aspx. If you’re thinking about moving forward with an offline root CA only because it seems like it’s more secure, but you don’t have a specific reason for doing so, I recommend you change gears and go ahead with an online enterprise root CA. While there are some security advantages to the offline root, most companies do not find those advantages to be worth the extra hassle that accompanies using an offline root CA. There are definitely usability trade-offs when going that direction.

In most cases, you’ll want to select Enterprise CA and proceed from there.

Root versus Subordinate (issuing)

This is the second big choice you need to make when building a new CA. Is your new server going to be a Root CA or a Subordinate CA? In some cases, even in a lot of Microsoft documentation, a subordinate CA is more often called an issuing CA. Generally, in a multi-tiered PKI, the subordinate/issuing CAs are the ones that do the issuing of certificates to users and devices in your network.

The difference really is just a matter of what you want your CA hierarchy to look like. In a PKI tree, there is a single high-level certificate, self-signed to itself by the root CA, that everything chains up to. A subordinate CA, on the other hand, is one that resides below a root CA in the tree, and it has been issued a certificate of its own from the root above it.

If your plans are to only run a single CA server, it must be a root. If you are creating a tiered approach to issuing certificates, the first CA in your environment needs to be a root, and you can slide subordinates in underneath it. You are allowed to have multiple roots, and therefore multiple trees, within a network. So your particular PKI can be structured however you see fit. In smaller companies, it is very common to see only a single CA server, an enterprise root. For the sake of simplicity in administration, these customers are willing to take the risk that, if something happens to that server, it won’t be that big a deal to build a new one and re-issue certificates.

For larger networks, it is more common to see a single root with a couple of subordinates below it. Typically, in this case, the root is only responsible for being the top dog, and the subordinate CAs are the ones doing the real work—issuing certificates to the clients.

Naming your CA server

At this point, now that you have installed the role, the hostname of the server itself is set in stone. You already knew this. But as you progress through the wizards to configure your CA for the first time, you will come across a screen called Specify the name of the CA. Huh? I thought we already did that when we set the hostname?

Nope, we do have our final hostname and that server name is plugged into Active Directory as my server is joined to the domain, but the actual “CA Name” is something else altogether. This is the name that will be identified inside the properties of every certificate that this CA issues. This is also a name that will be configured in various places inside Active Directory, since I am building an Enterprise CA. The wizard self-identifies a possible name for you to use, which many administrators simply take and use. If you want to configure your own name, this is where you should do it. Once you set the name here, this is the name of the CA forever:

Can I install the CA role onto a domain controller?

Since the role is officially called the Active Directory Certificate Services role, does that mean I should install this role onto one of my domain controller servers? No! Unfortunately, I have run across many small-to-medium businesses that have done exactly this, and luckily they don’t have too many problems. So technically, it does work. However, it is not a Microsoft-recommended installation path and you should build your CAs on their own servers; try not to co-host them with any other roles whenever possible.

Comments are closed.