Geek of All Trades: Certificates made easy: part 2

You can create and provision custom certificates relatively easily following this process.

Greg Shields

In my October 2011 column, “Certificates Made Easy,” I explained a simple step-by-step process to configure Active Directory Certificate Services (AD CS) and provision fully trusted server certificates using a nifty shortcut within IIS. That shortcut’s Web server certificate will suffice for a lot of uses, not the least of which is authenticating and encrypting Web traffic.

Sometimes, though, your certificate needs to go beyond the basic Web server certificate. These days, you’ll see certificate requirements pop up everywhere: Windows PowerShell, System Center, DirectAccess and a growing list of third-party applications. Face it: You can’t ignore AD CS any longer.

As much as you want to hate it, AD CS is quickly becoming one of those must-have services in every Active Directory forest. Once you get started with the basics of AD CS, you’ll realize you can indeed customize and deploy some of its “other” certificates with Windows Server 2012.

A real-world example

Once you learn the steps required to configure and provision one type of custom certificate, you can generate most others in a similar fashion. The difference is in the template. To keep things real-world, I’ll focus this step-by-step explanation on the special requirements in setting up certs for the new Windows Server 2012 Hyper-V Replica.

The AD CS configuration steps outlined in that October 2011 column are quite simple. Once you’ve followed the process, you will have added an Enterprise Root certificate authority (CA) into your domain. Domain-joined clients should also have the CA’s root certificate automatically deployed to their Trusted Root Certification Authorities store, thanks to that Enterprise Root’s Active Directory integration. They’ll need that root certificate if they’re to trust the certificates your Enterprise Root CA publishes.

Hyper-V Replica can use either Kerberos or certificate-based authentication between replica pairs. The latter approach is necessary if you want to encrypt the replication traffic between hosts. It’s also necessary if you’re replicating VMs between hosts that aren’t in the same domain. The Hyper-V Manager settings screen lets you configure either option (see Figure 1).

Figure 1 You can configure your Hyper-V Replica settings.

Generating a run-of-the-mill Web server certificate isn’t all that difficult thanks to the handy IIS shortcut. Unfortunately, Web server certificates don’t include the necessary features that the Hyper-V Replica certificate-based authentication requires. Click Select Certificate without a properly configured certificate and you’ll get an error message (see Figure 2).

Figure 2 Hyper-V Replica ensures you’re using properly configured certificates.

Hyper-V Replica certificates have to support both server authentication and client authentication with an exportable private key. These certificates also have special requirements for their Subject Name or Subject Alternate Name field, as Praveen Vijayaraghavan outlined in the Microsoft Virtualization Blog. To set up a replication relationship, the certificate in the primary server must meet the following conditions:

• Enhanced Key Usage (EKU) must support both client and server authentication.
• Set the Subject field or Subject Alternative Name using one of the following methods:
  • Set the Subject field to the primary server name, such as primary1.contoso.com; if the primary server is part of a cluster, ensure the subject field is set to the Fully Qualified Domain Name (FQDN) of the Hyper-V Replica Broker (install this certificate on all the nodes of the cluster)
  • The Subject field can contain a wildcard (such as *.department.contoso.com)
  • For a SAN certificate, set the Subject Alternative Name’s DNS Name to the primary server name, such as primary1.contoso.com; if the primary server is part of a cluster, the Subject Alternative Name of the certificate should contain the FQDN of the Hyper-V Replica Broker (install this certificate on all the nodes of the cluster)

To enable a server to receive replication traffic, the certificate in the replica server must meet the following conditions:

• EKU must support both client and server authentication.
• Set the Subject field or Subject Alternative Name using one of the following methods:
  • For a SAN certificate, set the Subject Alternative Name’s DNS Name to the replica server name, such as replica1.contoso.com; if the replica server is part of a cluster, the Subject Alternative Name of the certificate must contain the replica server name and FQDN of the Hyper-V Replica Broker (install this certificate on all nodes of the cluster)
  • Set the Subject field to the replica server name, such as replica1.contoso.com; if the replica server is part of a cluster, ensure there’s a certificate with the subject field set to the FQDN of the Hyper-V Replica Broker installed on all nodes of the cluster
  • The Subject field can contain a wildcard, such as *.department.contoso.com.

Vijayaraghavan’s statements are useful, but they can also be confusing if you’re inexperienced with AD CS. So let’s create the simplest possible certificate that will meet Hyper-V Replica requirements.

Create the certificate template

You start all AD CS certificates from a template. Just like a virtual machine (VM) template defines the starting point for a VM, a certificate template defines the rules for any certificates it generates. However, there’s no template that matches Hyper-V Replica requirements out of the box in AD CS. You’ll need to create your own. Here’s where certificate customization gets interesting.

Start by launching Certification Authority from the Server Manager Tools dropdown, then click on Certificate Templates. You’ll see a list of issued certificate templates (see Figure 3). You’ll return here in a minute. First, you need to create a template you can issue.

Figure 3 The Certification Authority console shows you a list of certified templates.

Right-click the Certificate Templates node. Then select Manage to launch the Certificate Templates Console. You already know every certificate starts from a template. You should also know every template starts from another template. Those templates are what you’ll find in the console view (see Figure 4).

Figure 4 The Certificate Templates Console has the templates you’ll need.

The Computer template provides a good starting point for a Hyper-V Replica certificate, so right-click Computer and choose Duplicate Template. Doing so launches a properties screen for the new template. For your simple Hyper-V Replica certificate, you can ignore most of these tabs, but you will need to adjust a few of them.

Under the General tab (see Figure 5), change the template display name to something you’ll later recognize. You may also change the validity period and renewal period if you wish. Check the box marked “Publish certificate in Active Directory.” This will let you request this certificate later using your CA’s Active Directory Enrollment Policy. This is set up already by default.

Figure 5 The General tab lets you change general settings.

You have to configure a Hyper-V Replica certificate to be able to export its private key. You can enable this with the checkbox in the template’s Request Handling tab.

You also have to identify a Subject Name for the certificate. For simple Web server certificates, that Subject Name is most often the requesting server’s FQDN. You want your Hyper-V Replica certificate to work with a variety of Subject Names, so under the template’s Subject Name tab, choose to Supply in the request. That way, you’ll have to define a Subject Name or Subject Alternate Name as you request the certificate.

There’s no configuration required in the template’s Extensions tab. You originally duplicated a Computer template to create our Hyper-V Replica template. You did this because the Computer template already includes both client authentication and server authentication in its list of Application Policies. You can think of these Application Policies as the “features” supported by certificates based on this template. The official term for these features is Enhanced Key Usage, or EKU.

Security is the final tab. Here you can assign Read and Enroll permissions to the users and groups that will generate certificates based on this template. Be particularly careful with templates like the one you’ve created here. This template has the requestor providing a cert’s Subject Name, so a malicious user could use the template to generate all manner of named and trusted certificates.

Click OK to set these properties and close the Certificate Templates console. Now you have one important (and easily forgettable) step to finish your Hyper-V Replica template. Back in Certification Authority, right-click Certificate Templates and choose New | Certificate Template to Issue. Select your Hyper-V Replica template and click OK. Now you’re ready to enroll.

Enroll your certificate

Enrollment is facilitated by your CA’s Active Directory Enrollment Policy. You set this up by merely installing an Enterprise Root CA. Start by navigating to one of the Hyper-V hosts upon which you’ll enable the Hyper-V Replica with certificate-based authentication. There, launch an empty Microsoft Management Console (MMC) and add the Certificates snap-in for the Computer account. Once loaded, right-click Personal | Certificates and select All Tasks | Request New Certificate (Figure 6).

Figure 6 Your local computer certificates.

Doing so launches the Certificate Enrollment wizard. Here you can enroll any certificate that’s been enabled for distribution by the Active Directory Enrollment Policy. Click Next through the wizard’s first two pages to get to the Hyper-V Replica template. Enrolling for this certificate requires supplying a Subject Name or Subject Alternative Name, so click the More Information link to do so.

This exposes the Certificate Properties screen (Figure 7). Here you’ll enter a Subject Name or Subject Alternative Name. For the simplest solution, use a wildcard in the Alternative Name. The Alternative Name for this certificate is *.company.pri. This lets the certificate work with any Hyper-V Replica host that has a matching FQDN.

Figure 7 Your certificate properties can include a wildcard.

Click OK and Enroll to add the certificate to your Hyper-V host’s Personal store. This store is the location where Hyper-V Replica will look for any certificate that meets its requirements. You’re looking for a Succeeded status (Figure 8). You can also click to view the installed certificate. Click Finish to complete the wizard.

Figure 8 You’ll see when the certificate is successfully installed.

And that’s the process for customizing and requesting certificates. Your final step in configuring Hyper-V Replica happens back in Hyper-V Manager. Launch Hyper-V Settings and click the Select Certificate button in Replication Configuration. If you’ve done everything correctly, you’ll see your recently installed and customized certificate (Figure 9). Congratulations—now you’re ready to create and enroll just about any certificate you need.

Figure 9 You can select your certificate in the Hyper-V Settings.

Painful, but useful

Certificates seem to have gotten a bad rap in the past. When I ask about certificates at conferences or training sessions, most of the time I get a roomful of blank stares. Certificates aren’t going anywhere, though. And signs are showing that they’re becoming ever-more necessary to support today’s IT requirements. All you need is a way to make them easy.

Greg Shields, MVP, is a partner at Concentrated Technology. Get more of Shields’ Geek of All Trades tips and tricks at ConcentratedTech.com.

Related Content

• Geek of All Trades: Fault-tolerant Hyper-V storage
• Geek of All Trades: Automate the wizard
• Geek of All Trades: The new certifications