Now 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.
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.
2. Enable the policy and check the two options below.
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.
6. Click on the Extensions tab. Highlight Application Policies and click Edit. Add Server Authentication.
7. Click on the Security tab and modify the Domain Computers group to enable Autoenroll. Close out the template and template window.
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.
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.
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.
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.
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.
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. On your subordinate CA and open the Certificate Template manager as shown below.
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.
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.
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.