Now that we have configured our subordinate CA, and have validated the configuration with PKI View (and the ADCS BPA - please see my previous blog posts), we must provide clients with a means to request certificates.
We have multiple options. We can request certificates at the command line with the certutil tool. However, this is not the most user friendly option. Group Policy can be used to distribute certificates as well. In other cases, we may simply want to request a certificate for a single user or single computer. If we install the Certificate Authority web enrollment role service...
we can request certficates using a rather user friendly web interface.
Note:
But before we can provide this option to our clients, we have to know the limitations of we benrollment. Some of these limitations have not always existed so that is something administrators familiar with Windows 2003 PKI will want to note.
This is perhaps the most important:
Certificate web enrollment cannot be used with version 3 certificate templates.
This caused a great deal of frustration for me because I had duplicated a template using the version 3 (Windows 2008) option.
This is another limitation of web enrollment:
Internet Explorer cannot run in the local computer's security context; therefore, users can no longer request computer certificates by using Web enrollment.
We can, however, paste a Base64-encoded certificate request into a text box and submit it to the CA.
***
What else do we have to know?
We cannot request a certificate using the web interface unless SSL is enabled on the IIS virtual directory certsrv, for example:
http://localhost/certsrv
(with SSL not yet enabled)
If I am at the CA, I can access the website by entering "localhost" as shown above, rather than entering the name of the server (PKI-Sub-CA-1 in my network). This can be used to troubleshoot.
But we cannot enable SSL unless we bind a certificate to the certsrv website.
At this point, we may observe the certificates available for binding and discover that we already have a certificate on the subordinate CA: the certificate issued to it by the root CA.
Stop!
Do not bind this certificate to the certsrv website.
IIS will let you do this but it is the incorrect type of certificate.
Yes, there are different types of certificates for different purposes.
The certificate issued by the root CA to the subordinate CA is designed for certificate signing (the CA signs the certificates it issues to clients).
This type of certificate cannot be used to authenticate the identity of a web server - not even the web interface for certificate requests of the CA itself.
We need to request a separate and distinct certificate for this role.
So, essentially, we will have the CA request a "web server" type certificate for itself (from itself).
At this point, you may realize that we are going in circles:
- The CA must request a certificate for itself so we can enable SSL.
- We cannot request a certificate because SSL is not enabled (and the existing CA certificate cannot be used for a website).
I'll present the solution in the following lines.
***
First, we have to duplicate a certificate template that can be used to issue certificates to specific clients. In our initial configuration (see the capolicy.inf files earlier), we opted not to load the default templates:
LoadDefaultTemplates=0
Note: you may have the default templates loaded so what follows immediately below may not apply to you.
We open the Certificate Authority console, highlight "Certificate Templates", right-click and select "Manage" in the menu:
There are multiple templates available. We select a template designed for a specific role. In this case, we want a certificate for a IIS web server (the web interface of our CA in fact) and there is a perfect template for that: the "Web Server" template. Right-click on the template and select "Duplicate Template":
This is where we must pay attention!
If we do not want to use web enrollment, we can use a Windows 2008 template as shown below:
If we want to use web enrollement, we must select Windows Server 2003 Enterprise. So we would check the first option instead.
Next, we are presented with nine tabs of template properties. Not all of them require additional configuration. However, we do need to provide a name for the new template. I named mine "PKI Web Server":
The validity period is 2 years by default but we can increase this to 5 years which was the maximum validity period that we configured for the subordinate CA (with the post installation script).
Optionally, we can publish the certificate in Active Directory.
There are two other changes I would like to make.
First, I want to require certificate manager approval before the certificate is issued to future requestors:
Second, clients need both read and enroll permissions to request the certificate:
Note: "Authenticated Users" includes all user accounts and computer accounts that have been authenticated by a domain controller. So these permissions apply to computers as well. If we want clients to be able to autoenroll for certificates (using Group Policy for example), we must also check the "Autoenroll" permission. It is not necessary in this case.
I mentioned earlier that certificates are designed to fulfill a particular role. We cannot use a Code Signing certificate to authenticate a web server and vice versa (a Web Server certificate to sign code). The Extensions tab of the certificate template show the purpose of the certificate. Here, we can see that this certificate can be used for "Server Authentication":
Note: it is possible for certain certificates to have multiple roles.
When we finish, we have an additional template configured for our specific needs:
We can now exit the template management window and return to the Certificate Authority console. With the Certificate Templates folder highlighted, we right-click and select "Certificate Template to Issue"
We select the PKI Web Server certificate template we just duplicated:
The certificate template is now ready for use:
Note: we could have used the default Web Server certificate template but if we want to customize our settings and permissions it is preferable to leave the default template with its default settings. If we change these, they may not be suitable for some other purpose in the future.
Now we are ready to request a "Web Server" certificate for our subordinate CA (valid for "Server Authentication"). That will be the subject of my next blog post.
To be continued...
Thank you for reading the article about PKI (Public Key Infrastructure) with ADCS, Part 8: web enrollment and certificate templates on the blog NEW TECH If you want to disseminate this article on please list the link as the source, and if this article was helpful please bookmark this page in your web browser by pressing Ctrl + D on your keyboard keys.