In my previous blog post, I explained that before clients can request a certificate from the issuing CA via the web interface, we must request and issue a separate certificate to the CA itself.
Separate? By separate, I mean a certificate besides the one granted to the issuing subordinate CA by the root CA for its role as a certificate authority. In addition to this certificate, the CA needs another designed specfically for server authentication. So we duplicated the "web server" template and now have a template suitable for "(web) server authentication".
***
First, we open IIS on the subordinate CA (PKI-Sub-CA-1 in my test network), select the CA and then (in the center pane) "Server Certificates":
In the right pane (not shown above - see below) we select "Create Certificate Request":
Note that the only existing certificate is the certificate issued for the (subordinate) certificate authority role by PKI-ROOT-CA. We cannot use this certificate for the web server role (or for server authentication in general).
We enter the required information in the resulting dialog box:
I keep the default CSP and select 2048 for the key length:
We save the certificate request as a text file (and click Finish):
Next, we open Internet Explorer on the subordinate issuing CA itself and enter the following URL:
http://pki-sub-ca-1/certsrv
Note: We enter http rather than https since the site does not yet have an appropriate certificate that would allow us to enable (or require) SSL. We can also enter "localhost" instead of the server name when we are at the CA itself.
We then click on the task "Request a certificate" (see above) which brings us to this page:
Select the second option.
At this point, I encountered the following error:
This can be caused by a number of factors:
- You simply do not have permissions to the template. In my case, I was connected with the default domain administrator account (test network).
- You used a Windows 2008 (v3) template when you duplicated the web server template. I made this mistake once but then duplicated the template a second time using the Windows 2003 option. For more information, this was discussed in my previous blog post.
- Others encountering the problem have suggested that we need to move NTLM above Negotiate under the Providers for Windows authentication. See "NTLM" 1 and 2 screenshots below.
- Yet others have suggested that the Application Pool Identity must be set to NetworkService. See the "Application Pool Identity" screenshot below.
***
NTLM 1
NTLM 2 - where do I find Providers?
Application Pool Identity
***
In one case, I was able to eliminate the error message after using a Windows 2003 version template. However, I had already moved NTLM above Negotiate and changed the App Pool ID to NetworkService. I was even able to change these last two settings back to their defaults and the templates remained accessible.
In another case, I selected the Windows 2003 version template but was only able to make the template appear after I set the App Pool ID to NetworkService.
Note: after making these changes, I did execute the command iisrest /noforce
All in all, it seems that we have to have the exact combination of some very particular settings for the templates to appear.
***
Once the templates are accessible, we continue the certificate request process as follows.
We open the certificate request file that we created earlier and then highlight and copy the entire content, including the request header and footer:
In the image above the text is not yet highlighted for copying and I "snipped" a portion of the content to show what I mean by the header and footer. In reality, you will not modify the content of the text file in any way. Simply copy it (all) as is...
And paste it here:
Lastly, click "Submit".
Since the certificate template was configured so it requires administrative approval, we now must wait until someone managing the CA approves and issues the certificate.
In this case, we are both the requestor and the CA administrator so we can now open the Certificate Authority console and browse to the Pending Requests folder:
We right-click on the certificate request, select "All Tasks" and then "Issue":
Once approved and issued, the certificate is moved to the "Issued Certificates" folder:
Now we can return to the web site where we submitted the request and view the status of our request. We click on the "View status (etc.)" link:
Note: here I use "localhost" in the Url which is an acceptable option as long as we are at the CA itself. Once we enable SSL on the site we will no longer be able to use "localhost" because this name will not be on the certificate.
We can see the certificate request:
We see that the certificate was issued and can be downloaded. In this case, we only need the certificate itself (not the chain) and will use the Base 64 encoded format:
There will probably be some sort of download prompt (depending on your browser settings):
We select a location to save the file:
Now we return to the IIS management console where we select the "Complete Certificate Request" option (click on the server icon in the left pane and then "Server Certificates" in the center pane):
We browse to the downloaded certificate and provide a name for it (click Next or Finish as needed):
Now we have the second certificate in place:
All we need to do is to bind it to the default website:
Select the certificate we just downloaded for https (port 443):
Once we have finished we can close Site Bindings...
And then enable SSL on the CertSrv website:
Now clients are able to access the website and request certificates.
***
At this point, we have a functional PKI and clients can either request certificates manually using the web interface or have certificates issued automatically via Group Policy, with membership in specific security groups determining exactly which certificates can be issued. Lastly, we could issue certificates to mobile users with (non-Windows) tablets or Smartphones using a third party product like AirWatch or MobileIron.
I may examine these options in future blog posts.
Even though my PKI is now functional, in a production environment we would have to consider aspects such as high availability, backups and key archiving. This series of blog posts does not address these aspects but they are, or course, crucial.
For the moment, and after nine blog posts about PKI, I will place this subject on "pause" so I can take a look at some other subjects that interest me.
Thank you for reading the article about PKI (Public Key Infrastructure) with ADCS, Part 9: web enrollment (web server certificate for the CA) 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.