When you install Certificate Services on Windows 2003 and Windows 2008, you have the option to add Web Enrollment Pages. These pages are needed if you need a higher level of assurance for your certificates than Auto Enrollment provides. In other words, they facilitate a process by which:
- A user submits a request for a certificate, which is stored in a queue on a Windows Certificate Authority.
- The request is independently authenticated by a 3rd party entity
- The approved digitally signed certificate is provided back to the user
The key here is Step 2, which strongly ties the identity of the requestor to the actual request. This goes beyond the simple user ID and password requirement and adds a layer of authentication that is required for implementing the federal standard for Basic Assurance.
The problem with the Web Enrollment Pages is that out-of-the-box only the default User Certificate template is presented on the request page. This screenshot shows what the default page looks like when a user selects "Request a Certificate".
If you have other templates that you wish to deploy, you could ask your users to ignore the User Certificate template as shown in the screenshot and submit an "advanced request". They could then select the appropriate certificate from the Certificate Template drop-down list box, but that approach would likely lead to a lot of confusion.
Furthermore, the entire dialogue in various enrollment pages isn’t very helpful in guiding end-users throughout the enrollment process. If you’re going to adopt Public Key Infrastructure as a key part of your security infrastructure (and you should!), than you need to pay attention to little things like this.
The good news is that customizing these pages is quite straightforward. You can find them in: c:windowssystem32certsrv. The following table describes the relevant files that can be customized.
Presents certificate types to users as a link on the "Request a Certificate" page.
Final response page after the request is submitted.
Let’s start with certrqtp.inc. If you have some custom templates that you wish for users to be able to request by default, this will need to be updated. The following example exposes two Certificate Templates that I created in Certificate Services in Web Enrollment. I highlighted my changes in blue.
<% ‘ CODEPAGE=65001 ‘UTF-8%>
<% ‘ certrqtp.inc – (CERT)srv web – (R)e(Q)uest, available (T)y(P)es
‘ Copyright (C) Microsoft Corporation, 1998 – 1999 %>
‘ NOTE: certdat.inc must be included first!
‘ Strings for localization
Const L_WebBrowserCert_Text="Web Browser Certificate"
Const L_EmailProtectionCert_Text="E-Mail Protection Certificate"
Const L_UserTemplateCert_Text="User Certificate"
Const L_AdatumVPNCert_Text="ADATUM VPN Certificate"
Const L_AdatumClientAuthCert_Text="ADATUM Client Authentication Certificate"
If "StandAlone"=sServerType Then
‘ Request types for stand alone
rgAvailReqTypes(0,FIELD_CSPLIST)="Microsoft Enhanced Cryptographic Provider v1.0?Microsoft Base Cryptographic Provider v1.0"
rgAvailReqTypes(0,FIELD_CSPLIST2)="Microsoft Base Cryptographic Provider v1.0?Microsoft Enhanced Cryptographic Provider v1.0"
rgAvailReqTypes(1,FIELD_CSPLIST)="Microsoft Enhanced Cryptographic Provider v1.0?Microsoft Base Cryptographic Provider v1.0"
rgAvailReqTypes(1,FIELD_CSPLIST2)="Microsoft Base Cryptographic Provider v1.0?Microsoft Enhanced Cryptographic Provider v1.0"
So I hope you would agree this isn’t Earth shaking stuff. All we’re doing is adding some data to the .asp code to reference more templates. NOTE: Before making these kinds of changes, I highly recommend backing up (or re-naming) the original file.
As a result of these changes, the end user sees the following:
The default "User Certificate" template is gone and has been replaced with two new templates that I created for my environment. No need for folks to fill out an "advanced request" to get them.
It may also be beneficial to customize certsrpn.asp, which is the response page that is presented to the user after the original submission is made and is placed into the approval queue. This will provide end-users some good information on what will happen next.
40: <%If 0<>InStr(sMode,"newreq") Then%>
41: <P ID=locInfoNewReq> Your certificate request has been received. The helpdesk will validate
your request and you will be contacted within two business days.</P>
43: <P ID=locInfoReqID>
44: Your Request Id is <%=nReqID%>.
47: <%ElseIf "chkpnd"=sMode Then%>
48: <P ID=locInfoChkPnd> Your certificate request is still pending. The helpdesk is currently
evaluating your request. If you have any questions, you may contact the helpdesk at (800)123-
49: <%End If%>
51: <P ID=locInstructions> You receive an email notification when your certificate has been
issued. Further instructions will be provided.</P>
52: <P ID=locTimeoutWarning><Font Size=-1><B>Note:</B> You must return with <B>this</B> web
browser within <%=nPendingTimeoutDays%> days to retrieve your certificate</Font></P>
The result of such a customization would look like this:
So you can see that by making some straightforward changes to the Web Enrollment pages, you can customize the process to meet your specific workflow and communication requirements and give your end users a much better experience.
By the way, if you’re serious about deploying digital certificates in your environment, you really should take a good look at Certificate Lifecycle Manager (CLM), which is part of Microsoft’s Identity Lifecycle Manager 2007 product. CLM provides an even better enrollment portal the goes way beyond just basic certificate requests. For example, CLM gives you ability to require the user provide supplemental information as part of the request, like employee ID number.
In any event, I hope this is helpful for anyone out there looking at building a PKI and an enrollment process.