Windows Server 2012 R2 Two-Tier PKI CA Pt. 3

1-10-2014 6-57-56 AMNow that we have our Windows Server 2012 R2 certificate authority configured in Part 1, and our subordinate setup in Part 2, now we should setup autoenrollment and secure the subordinate’s web certificate services with SSL. Autoenrollment is where domain joined Windows computers are automatically issued a computer certificate. Services such as IIS and Microsoft SCCM can take advantage of these certificates. Finally, I’ll show you how to configure certificate delegation so authorized administrators in your organization can submit certificate requests for certain templates. This is a short series, at just three installments. But this should point you in the right direction for thinking about how to deploy your two-tier Certificate Authority on Windows Server 2012 r2.

Autoenrollment Configuration

1. Open your domain level GPO (Default Domain Policy in my case) and navigate to Public Key Policies as shown in the figure below. Double click on the highlighted policy.

1-4-2014 8-51-24 PM

2. Enable the policy and check the two options below.

1-4-2014 8-51-07 PM3. On your subordinate CA, open the CA snap-in and manage the Certificate Templates as shown below.

1-4-2014 8-54-37 PM4. Scroll down and locate Workstation Authentication. Right click and Duplicate the template.

5. Click on the General tab and enter a template name (any name). I’ll use Client-Server Authentication. I also changed the validity period to 2 years.

1-4-2014 8-58-07 PM

6. Click on the Extensions tab. Highlight Application Policies and click Edit. Add Server Authentication.

1-4-2014 9-00-46 PM

7. Click on the Security tab and modify the Domain Computers group to enable Autoenroll. Close out the template and template window.

1-4-2014 9-01-46 PM

8. Back in the issuing CA console right click on Certificate Templates, select New, then Certificate Template to Issue. Select the template name you just created. Wait a few minutes for the settings to simmer a bit. If you want you could also publish the Domain Controller template. This will enable the DCs to offer LDAPS services. If the template you just created is not listed, you can simply wait a bit or restart the CA services and that should kick it in the pants.

windows server 2012 r2 certificate authority

Autoenrollment Validation

1. Open an elevated command prompt or Powershell and type gpupdate /force. Wait a couple of minutes, as certificate enrollment is not always instant.

2. Open a blank MMC console and add the Certificates snap-in. Manage the Computer account.

1-4-2014 9-14-11 PM

3. On your subordinate CA you should now see two certificates. In my case the top certificate was the one issued by the autoenrollment policy.

1-4-2014 9-16-20 PM

4. You can verify the certificate was issued from the proper template by opening the properties then on the Details tab look for the Certificate Template Information property. It will clearly state the template name used to create the certificate.

1-4-2014 9-17-29 PM

5. As the GPO refreshes on other computers in the domain, they should also be issued a certificate as well. Autoenrollment can run into snags, so I have seen cases where everything has been configured properly but for some reason a certificate is not issued.

Configure CA Web Services for SSL

1. After the autoenrollment certificate has been validated on the subordinate CA, open the IIS Manager on your subordinate CA.

2. In the left pane select Default Web Site. In the right pane select Bindings.

3. Click on https then click Edit.

4. Select the SSL certificate that was created from the client-server template. You can view the certificate in the GUI if you aren’t sure which one to pick.

1-4-2014 9-35-37 PM

5. Open IE and navigate to the FQDN of your subordinate CA and to the certsrv site (e.g. https://D002Misc01.contoso.local/certsrv). You will likely be prompted for credentials, then presented with the standard ADCS home page. You should not have any SSL errors or warnings.

1-4-2014 9-39-32 PM

Template Delegation

1. On your subordinate CA and open the Certificate Template manager as shown below.

1-10-2014 7-26-06 AM

2. Locate the certificate template which you want to delegate. In my case I have a VMware-SSL template that I want to delegate to the group we created earlier in this series. Open the properties for the certificate template and select the Security tab. Add the Role_Issue Certificates group (or whatever your group is called) and give it the Enroll permission.

1-10-2014 7-28-14 AM

3. Optionally you configure the CA to allow requests to be submitted, but require a CA administrator to approve the certificates before they can be issued. If you want to do this, open the Issuance Requirements tab and check to the CA certificate manager approval box. This would defeat the purpose of autoenrollment certificates, such as those for computers, so generally this would be for certificates that users are requesting.

1-10-2014 7-32-51 AM

What’s Next?

If you want to issue SSL certificates for your VMware infrastructure, then you can check out my post here for the template requirements. Although that article is for vSphere 5.5, the template will also work for vSphere 4.x and 5.x. Now you have a fully functional, for lab/home usage, offline root and online subordinate CA. As I stated in Part 1, this guide just shows you the general technical steps for a two-tier Certificate Authority. There’s a lot of processes and procedures that an organization needs to flesh out and document before deploying PKI in the environment. There could be legal or other consequences if you just throw this on a production network and then down the road experience security issues which can be traced back to a poorly implemented CA.

Windows Server 2012 R2 Two-Tier PKI CA Pt. 1

windows server 2012 R2 certificate authorityWhile I have written a number of articles focused on SSL certificates and templates, I have not done a mini-series on how to actually install a Windows Certificate Authority. For this series I’m using Windows Server 2012 R2, but the steps are pretty much identical for Windows Server 2012. Microsoft blogs have several PKI configuration series, which directly guided the content of this series. But I always have my own spin, so I think its worthwhile to do yet anther blog post on configuring a MS CA…the “Mr. SSL” way.

Windows Server 2012 R2 Certificate Authority

The process is fairly simple: Build an offline root, create an online issuing CA, setup a couple of templates, setup auto-enrollment, then do a little post setup configuration. This requires two VMs, each running Windows Server 2012 R2 (or plain 2012 if you wish).

Building an enterprise CA is non-trivial, and should be highly process oriented. While this short series will provide the steps how to configure a two tiered hierarchy, it alone is not enterprise grade and ready for a fortune 500 company. Many operational procedures, access controls, etc. need to be defined by the organization. For example, who can issue certificates? Who can revoke them? Do users need PKI certificates or just computers? How about key recovery? Disaster recovery? Do you need a hardware security module (HSM)? Do you require FIPS compliance? What ciphers and hashing algorithms will you allow? Where do you store the offline CA?

As you can see, there are many questions and processes that need to be well documented for a solid PKI solution. However, for a lab environment where you want to test out a two-tiered model, then this short series is for you. Please don’t take this solution as-is and throw it into production. You will have a false sense of security and possibly do more harm than good.

The Microsoft CA issues industry standard certificates (x.509), and thus will work with third party hardware and software. For instance, they will work perfectly fine on the Linux vCenter appliance, or your hardware load balancers. You just need to use the proper certificate template, and verify compatible algorithms.

Offline Root CA Hardening

1. Provision a standalone Windows Server 2012 R2 server. I used vCenter 5.5 with customization specifications to create the VM. You can use the ‘standard’ edition of the OS since all SKUs in 2012 have the exact same feature set, unlike 2008 R2 and earlier. For security purposes I would not provision a NIC, or remove the NIC after you’ve built the CA to prevent future network attacks.

2. Configure a virtual floppy for the offline CA VM. This is a good way to transfer data between the offline CA and the subordinate, which is required during the configuration process. Yes you could connect a NIC, but then your offline CA is no longer offline and exposed to network attacks. Media needs to be read/write, so an ISO image will not suffice. You can use a tool like WinImage to create a floppy image.

3. Open the local security policy and modify the Audit Object Access to record Success and Failures. This is needed to audit certain CA actions, in conjunction with a CA flag we will set later on.

1-5-2014 1-18-44 PM

4. Depending on your VM template hardening, you may or may not need to modify the password policy. Again in the Local Security editor. Modify to meet your organization’s security requirements.

1-5-2014 1-23-08 PM

5. You should also rename the Administrator account, if that’s not already built into your templates. Make sure to record the new name, or you could be in a pickle. For good measure I’d rename the guest account, although it should be disabled.

1-5-2014 1-25-28 PM

6. Obviously you should change the administrator password and not use your template default. Be sure to record the password in a secure location.

7. You should also think about where you will store the offline CA VM once it is build and this project is complete. If you leave it sitting on a production ESXi host, then it would be fairly trivial to power on the VM and compromise it. I would not call storing your “offline” CA in a powered off state on a production ESXi host “offline”. I would look at exporting the VM to an OVF file, then storing that file on removable media in a very secure location. You could use a DVD, Blu-Ray, or USB stick.

Install Offline Root CA

1. After your VM is provisioned and hardened, make sure the computer name is configured. In my case the offline CA is name D002CA01. Reboot if you changed the name.

2. Use Notepad and create a file called CAPolicy.inf in C:\Windows. Use the code snippet below, but change the URL. This URL is where your Certification Practice Statement (CPS) is located. It will also be where the CRL (certificate revocation list) will be published. For a production deployment you’d want to create a CPS, but for this exercise we will skip it, however the URL will be configured for future usage. For additional details see this TechNet link. You probably want to use a different URL like CA.yourdomain or PKI.yourdomain since we will be publishing other data to this address such as the CRL. For simplicity I stuck with www.contoso.local. Make sure the filename does not have any extra extensions like .txt. Verify from the command line.

Signature="$Windows NT$"
Notice="Legal Policy Statement"

3. Run the following PowerShell command. Change the CACommonName as needed. The command will complete instantly. I would make it clear in the name that this is the Root CA. This name will be present in all issued certificates, so make it obvious what it is and not just some generic hostname that is not meaningful. Notice that we are using SHA256 here, since SHA1 is no longer considered secure. You could also use SHA512.

Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools

Install-AdcsCertificationAuthority –CAType StandaloneRootCA –CACommonName "ContosoRootCA" –KeyLength 2048 –HashAlgorithm SHA256 –CryptoProviderName "RSA#Microsoft Software Key Storage Provider"

1-4-2014 2-05-36 PM

4. Run the following commands, using the appropriate URL for your organization. We aren’t using HTTPS here, because that requires SSL and certificate validation. This is just used to download the CPS and CRLs, so don’t get clever and use HTTPS here. We will configure SSL for the web enrollment module, though.

$crllist = Get-CACrlDistributionPoint; foreach ($crl in $crllist) {Remove-CACrlDistributionPoint $crl.uri -Force};
Add-CACRLDistributionPoint -Uri C:\Windows\System32\CertSrv\CertEnroll\%3%8.crl -PublishToServer -Force
Add-CACRLDistributionPoint -Uri http://www.contoso.local/pki/%3%8.crl -AddToCertificateCDP -Force
$aialist = Get-CAAuthorityInformationAccess; foreach ($aia in $aialist) {Remove-CAAuthorityInformationAccess $aia.uri -Force};
Certutil -setreg CA\CRLOverlapPeriodUnits 12
Certutil -setreg CA\CRLOverlapPeriod "Hours"
Certutil -setreg CA\ValidityPeriodUnits 10
Certutil -setreg CA\ValidityPeriod "Years"
Certutil -setreg CA\AuditFilter 127
restart-service certsvc
certutil -crl

5. Verify that two and only two CRL distribution points are configured.

Get-CACRLDistributionPoint | format-list

1-4-2014 3-12-39 PM6. Navigate to C:\Windows\System32\CertSrv\CertEnroll. You should see two files, one ending in CRL and another ending in .CRT. These two files need to be copied to what will be the online subordinate CA.

1-4-2014 4-17-37 PM

Publish Root CA to the Forest

1. Provision a Windows Server 2012 R2 VM which will be your online CA. Join it to the domain. In my case the VM is named D002MISC01. Do not try and be clever and use a Domain Controller. The server will later need IIS installed and access to local accounts, which is not possible on a DC. So use a member server for your online CA, even in a home lab.

2. Login to what will be your online subordinate CA with an account that is a member of both Domain Admins and Enterprise Admins. Mount the media which has the two files copied from your offline CA. Open an elevated Powershell and enter the following commands, using the file names for your instance. This will publish the offline root CA information to AD, just as if it were an online CA. By doing this all domain joined clients will automatically trust your root CA. If you have standalone computers, then you can import the .crt file into their trusted certificate store.

certutil –dspublish –f D002CA01_ContosoRootCA.crt RootCA
certutil –addstore –f root D002CA01_ContosoRootCA.crt
certutil –addstore –f root ContosoRootCA.crl

1-4-2014 4-19-11 PM

CPS and CRL Distribution

1. Now you need create a DNS record for the host that will be publishing your online CA information. In this case it’s D002MISC01, and per my previous steps I stuck with ‘www’ as the site name. I’m assuming the proper DNS zone already exists, since you have a domain with Active Directory up and running. This must be configured prior to continuing, as the subordinate will fail to properly configure if the CRL file is not available.

1-4-2014 4-25-31 PM

2. We need to install IIS, since we will be distributing the CPS and CRL via the HTTP. On the VM which will be your online CA, run the following command:

Install-WindowsFeature Web-WebServer -IncludeManagementTools

3. Open an elevated PowerShell and enter the following commands. If you have an official CPS, then you can skip the second command and just copy your cps.txt file to the directory. For security purposes I’d recommend putting the files on the D: drive, so you aren’t serving content from the OS drive.

new-item -path D:\pki -type directory
write-output "This is a sample CPS. Modify as needed." | out-file D:\pki\cps.txt
new-smbshare -name pki D:\pki -FullAccess SYSTEM,"Contoso\Domain Admins" -ChangeAccess "Contoso\Cert Publishers"

4. Open the IIS Manager and add a Virtual Directory as shown below.

1-4-2014 7-19-27 PM

1-4-2014 7-20-39 PM

5. Verify pki is selected in the left pane, then single click Authentication in the middle pane, and in the right Actions pane click on Edit Permissions.

6. Select the Security tab and select Edit. Add the Cert Publishers group with Modify permissions (which will add several others under it).

1-4-2014 7-10-14 PM

7. In the same dialog box, click add but change the from this location to the local computer. Manually enter IIS AppPool\DefaultAppPool. Leave the default permissions. If you use the user/group browser this will not be listed, so please manually enter it.

8. At this point any anonymous browser can now read your CPS statement and see the public root certificate. You can test this by going to http://www.yourdomain/pki/cps.txt and verify the sample file opens.

9. In the middle pane, with pki still selected, click once on Request Filtering. In the right pane click on Edit Feature Settings and check the box next to Allow double escaping.

1-4-2014 7-12-45 PM

10. Run iisreset from an elevated Powershell command.


In this installment we’ve configured our offline root CA, performed some hardening, and published the root CA information to the domain. All computers in the domain will now trust your root CA. We also configured IIS to serve up your CPS and CRLs to anonymous users. Next up is configuring the online subordinate CA. Check out the next installment in Part 2.

Create Windows CA VMware Certificate Template

In any enterprise environment, small or large, you should always used trusted SSL certificates for your VMware components. Very commonly people want to use a Microsoft Certificate Authority (CA). But, VMware requires certain properties be present in the SSL certificate to properly function. So you need to create a custom VMware certificate template in your CA to accommodate the key requirements.

You will need to modify the default Microsoft CA Web Server template settings to meet published VMware certificate requirements. vSphere 5.0 and earlier had an additional certificate requirement (nonrepudiation) that is not required in vSphere 5.1. This article will show you how to create a Microsoft CA template with all the past and present requirements, so that your bases are covered.

The default Web Server certificate template it does NOT have Data Encipherment, nonrepudiation, or client authentication enabled. Depending on the version of vSphere you are using, one or more of these properties may be required. So while the CA will happily issue you a certificate if you request these features, it will silently ignore the unsupported key usage specified in your CSR, which may cause you problems.

These instructions are based on Windows Server 2012, but all the options are available in prior Enterprise versions of the OS, such as Windows Server 2008 R2. You may have problems with “standard” edition CAs prior to Windows Server 2012, as they lack some certificate features found in Enterprise or higher editions. Windows Server 2012 standard edition has the full compliment of certificate options, so datacenter edition is not required (there is no enterprise edition).

If you are interested in the full 15-part vCenter 5.1 installation series with trusted SSL certificates, click here.

VMware Certificate Template Creation

1. Open the Certificate Authority tool. Locate the top Certificate Templates, right click, and select Manage. 

certificate authority
2. Locate the web server template and duplicate it.

3. Don’t change any of the compatibility settings. Leave it on Windows Server 2003.

4. Since this template will be used for VMware SSL certificates I named the new template appropriately. I also changed the validity period to three years, but the period the certificate is actually issued with depends on other CA properties so it may not be the full period you specify here.
 5. Open the Extensions tab, click on Key Usage, then select Signature is proof of origin and Allow Encryption of User data. Note: ESXi 5.1 does not require nonrepudiation or dataencipherment (encryption of user data). But I’ve enabled them here for backwards compatibility.
6. In the Extensions tab click Application Policies then click Edit.  Add the Client Authentication policy. Note: The vCenter 5.1 services do not require the Client Authentication option, but I’ve included it here for backwards compatibility with vCenter 5.0 and earlier. It appears ESXi 5.1 still wants client authentication.
7. On the Subject Name tab make sure Supply in the request is selected (it is by default). This will let us issue certificates with a SAN (subject alternative name).
4-22-2013 9-00-46 PM
8. After the template is made, you now have to permit certificates to be minted using that template. Right click on the Certificate Templates node as shown below, select New, then Certificate Template to Issue.

9. Select the VMware SSL template, or whatever name you used.

10. If everything went as planned you will have a new certificate template type when submitting a CSR. If you don’t see your new template, you may not have appropriate CA rights to issue the certificate.
11. To validate everything is working as planned, submit a CSR that has the Data Encipherment, nonrepudiation, and client authentication key requirements, then open the properties of the certificate. As you can see in the screenshots below, our minted certificate has all the required properties. If you have no idea how to create a CSR with these extra usage options, don’t fear, just read my blog post here. You are now ready to issue the proper SSL certificates for all of your vSphere environments.
Congrats! You now have a VMware certificate template that you can use with all modern versions of vSphere without fear of ignoring an important key usage attribute.

How to create custom Microsoft CA SSL certificate templates

There are a variety of ways to create a trusted SSL certificate in the Windows world, but this article will focus on an internal network that has a Windows Server 2008 R2 Certificate Authority and member servers. This guide will show you how to create a custom Microsoft CA SSL certificate template. This can be very useful for VMware environments, where you may need to tweak certificate template properties.

IIS has a built-in domain certificate request wizard, but you can’t specify a custom web server certificate template to use. The built-in Web server template in the Microsoft CA is fine and dandy, but you might want to customize the certificate to extend the validity period, increase the key length, allow private key exporting, or a variety of features. Or you may have other enterprise services that can use certificates stored in the Microsoft computer certificate store, such as VMware View 5.1 connection server.

Whatever the case may be, the steps below will show you how to create a custom Microsoft CA SSL certificate template in your Microsoft CA, then perform a certificate request using that custom template.

Create the Microsoft CA SSL Certificate Template

1. Logon to your Microsoft Root CA and open the Certificate Services MMC. Expand the first Certificate Templates tree, which should reveal more than 30 Certificate Templates.

2. Right click on Web Server, duplicate the template, and then select either template type, but I choose Windows Server 2003 Enterprise. The 2008 template gives you more options, and is required if you want to use Suite-B encryption algorithms like elliptical curve. However, the Windows Server 2008 certificate template will NOT work with VMware View 5.1 connection server, so use 2003 instead.

3. Modify the template display name and validity period to suit your needs.

4. Click on Request Handling and change the key suite to suite your needs, and optionall check the option to allow the private key to be exported. This is REQUIRED for VMware View 5.1 Connection server to work. If you aren’t using VMware Connection Server 5.1, only check the box if you need to as it has security implications. You can also increase the key size here as well, if you want.
5. Click on the Security tab. What we need to do here is allow web servers to Enroll in this certificate type. There are several ways you could do this, with varying levels of security. One way for a non-secure lab environment is add Domain Computers to the access list and give them the Enroll permission.
However, that would allow any domain joined computer to request a web server SSL certificate, which outside of a lab is not ideal. To add a little more security I created a security group, following my RBAC naming convention, of ACL_Certificates_WebServer_Enroll and gave that group Enroll permission.

6. Click OK to close the template properties and create the new template.

7. Next, we need to make the certificate available to computers. To do this, right click on the second Certificate Templates container, as shown below. Select New -> Certificate Template to Issue. In the next window select the template that you just created.

You should now see your custom certificate template listed, as shown below. At this point you can stop, as the certificate authority is now properly configured to issue a web server certificate template.

8. If you created a group that can enroll in this certificate type, then place the computer object into the group and reboot the server, so it gets the new group membership. If you went the easy route of adding Domain Computers to the enroll permission, no reboot is needed.

Request New Certificate

1. To request a new certificate using the freshly created template, logon to the server that needs the SSL certificate and open a blank MMC then add the Certificates snap-in for the Computer account.

2. Once the MMC console is added, expand down to the personal certificates store and right click on Certificates. Select All Tasks then Request New Certificate.

3. Click through the wizard until you get to the Active Directory Enrollment Policy. Select the new web server template that you just created. Then click on More information is required…

4. In the Certificate Properties page you need at a minimum the Common name, which should be the FQDN of your web server. When I configured an alternative name using the server’s short name, I got some weird certificate issues in IE and View, so I’d just stick with configuring the common name with the FQDN and no other fields. Click Add to add the properties to the certificate request.

5. Close out the certificate window and click on Enroll. If all goes well, you should now have a new certificate listed in the MMC.

If you are using Microsoft IIS, you can now configure IIS to use the new custom web certificate. Or if you are using other products such as VMware View 5.1 connection server, you now have a SSL certificate you can use. Enjoy!