Setting up your own mechanism for generating security certificates is nowhere near as complicated as many seem to think.
You’ve seen this a million times before. Perhaps it’s in an article on securing IIS, or maybe it’s one of the steps in signing a Windows PowerShell script. It’s arguably one of the most reviled statements you’ll come across in any IT knowledgebase article. It goes something like this: “Install a trusted certificate using an internal Certificate Services server or by purchasing one from a public certificate authority [CA], then …”
Argh. Certificates are the bane of our existence. Installing them is far too often a work-stopping hurdle. You generally have two options. The first costs you nothing but the time and effort required to set up your own Certificate Services server. The second requires that you purchase a certificate from a trusted third party, which can be expensive. Just getting the cost approved can be a challenge.
Certificates are seemingly everywhere as mechanisms for authentication and data encryption. You could argue that certificates aren’t that important, though. Compared to other solutions, they’re an easy way to fulfill a security requirement. With a fully functioning Active Directory Certificate Services (AD CS) server and the proper root certificates on every desktop, generating and deploying a certificate costs you nothing but a few minutes and a few clicks.
However, the steps to construct an AD CS infrastructure are often believed to be an arcane art. Search for “installing certificate services,” and you’ll find a lengthy list of references, including guides, books and blog posts that may likely confuse more than assist.
One reason behind this complexity lies with the scalability of AD CS. Its Windows Server role can serve the needs of a company of 80,000 just as easily as one of eight. It has all the auto-enrollment bells and whistles a large company requires. Those bells and whistles, however, sometimes smother smaller groups with unfathomable complexity.
Setting up your own AD CS server bestows many benefits, not the least of which is eliminating the need to buy certificates from someone else. What you might not know, however, is that building a simple one isn’t all that challenging. The trick is ignoring most of what you read—except, of course, what you read next.
Setting up your own AD CS server requires little more than an instance of Windows Server. Either the Standard Edition or Enterprise Edition will do. In this example, you won’t be using auto-enrollment or modifying certificate templates. You’ll only have access to these and other advanced functions when you install AD CS atop Windows Server Enterprise Edition.
Certificate Services also requires little in terms of server resources. You can install it on an existing server already performing another task, or even a lightly configured virtual machine (VM). If you decide to share the AD CS role with other functions, be careful; decommissioning an AD CS server can mean starting this process all over again.
Launch Server Manager on your server and install the AD CS role with the Certification Authority role service. You’ll be prompted with several questions to begin installation. The first defines Setup Type. The simplest AD CS configuration is standalone mode, so select that mode when prompted.
You would commonly implement AD CS servers in large environments within a hierarchy. One or more Subordinate CAs would work in combination with an offline Root CA. Your simple implementation here only requires a single Root CA. Configure your server with this setting in the next screen.
Then you’ll be asked a series of questions about creating a Private Key for the server. Create a new Private Key and select the defaults for configuring Cryptography and your CA Name. You’ll also need to select a Validity Period, which defaults to five years. This Validity Period identifies the longest period of time any certificate is allowed to “live.” Selecting a longer Validity Period here means granting yourself a longer period of time before needing to update your CA’s root certificate. Finally, choose a location for your certificate database and its log files.
There, you’ve installed your AD CS server. Assuming you installed this server as a Domain Administrator, it will automatically begin populating its root certificate onto every computer in your domain. If you’ve done everything correctly, you should soon find the AD CS server’s root certificate in the Trusted Root Certification Authorities store on a computer. The root certificate for the AD CS server in this example is highlighted in the Certificates Microsoft Management Console (MMC) (see Figure 1).
Figure 1 The Root CA root certificate in Certificate Manager.
Because this root CA certificate is located in your Trusted Root Certification Authorities store, this computer will now trust any certificates issued by your AD CS server. This level of trust is exceptionally powerful. It lets you automatically issue certificates for any specific purpose, like enabling HTTPS on an IIS server. Let’s look at the steps you’ll use to do this.
You have to create a Domain Server Certificate to enable HTTPS in IIS. Do this in the IIS Manager console by selecting the server name, double-clicking Server Certificates, and then clicking the link titled Create Domain Certificate in the Actions pane. You’ll see a wizard that prompts for the certificate’s required information. Enter that information and click Next.
The wizard’s second screen can be somewhat confusing. The Select button isn’t always available to automatically select an AD CS server. If the button appears grayed out, enter the CA names followed by the server name (see Figure 2). The CA in this example is entitled company-DC-CA on the server DC. You’ll also need to enter a more “friendly” name for your CA server.
Figure 2 Specify an Online Certification Authority.
Click Finish to request the certificate. By default, AD CS requires administrator approval to issue a certificate, so you’ll likely see an error message. This error message lets you know the certificate request was successful, but the authority didn’t automatically issue the certificate (see Figure 3).
Figure 3 This message indicates a successful request, pending certificate issuance.
Return to the CA console and click on Pending Requests. You should see the requested certificate. Right-click the request and select Issue to issue the certificate (see Figure 4). At this point, transferring that issued certificate back to IIS requires an export and import process from the CA to the IIS Manager.
Figure 4 Issue the certificate.
In the CA console, click on Issued Certificates and double-click the certificate to transfer. Select Details | Copy to File to launch the Certificate Export Wizard. Export the certificate to a file as a DER encoded binary X.509 certificate with a .cer extension.
Finally, back in the IIS Manager, select Complete Certificate Request and point the resulting wizard to the file you’ve just created. You can now use that certificate for enabling HTTPS communication.
You have to take those extra steps because AD CS in Windows Standard Edition can’t use Active Directory to verify who’s permitted to request certificates. As a result, certificates remain in Pending Requests until you manually issue them. You can adjust a setting in the AD CS server’s Policy Module to allow automatic approval of all certificates, but that’s not a great idea. Enabling automatic issuance would let anyone create an automatically approved certificate for any purpose—not exactly a security best practice.
Windows Server Enterprise Edition includes other features that make it a worthwhile candidate for AD CS. You can customize certificate templates and issue certificates for special uses (called v2 and v3 certificates) like signing Windows PowerShell scripts. This requires a Code Signing certificate that isn’t available to AD CS in Windows Server Standard Edition. Other Windows Server Enterprise Edition features let you upgrade a simple AD CS instance into a full-featured PKI infrastructure.
See, certificates really aren’t that bad. Goodness knows you need them. Creating your own certificate infrastructure doesn’t need to be difficult. Just start simple with your CA design.
Not a TechNet Subscriber?
Confidently evaluate Microsoft software and plan deployments with a Microsoft TechNet Subscription.