If you have deployed your own internal PKI solution based upon Microsoft Certificate Services, there are several scenarios where you may want to issue certificates to the ISA Server computer, or individual array members if you are using Enterprise Edition. These certificates might be for use with internal web listeners, VPN services or even to support system management applications like the System Center Configuration Manager (Native Mode) agent.
Due to the limitations imposed by the ISA Server RPC filter on certificate requests (because they use RPC DCOM which is blocked by ISA Server system policy by default) it is common place for certificates enrolment using the certificate services MMC or autoenrollment to fail on ISA Server computers. Therefore, submitting certificate requests via web enrolment has been a useful way to achieve this process directly from the ISA Server computers (or array members) themselves.
However, as discussed in KB922706 titled How to use Certificate Services Web enrollment pages together with Windows Vista or Windows Server 2008, several useful features have been deprecated when using Windows Server 2008 Active Directory Certificate Services web enrolment or Windows Server 2003 Certificate Services web enrolment with KB922706 installed.
The most notable (and relevant to this blog entry) of these changes is the lack of support for automatically installing a computer certificate in the local computer store via the web enrolment interface. This is discussed in the extract below:
The Windows Vista certificate enrolment client component has been enhanced over that of earlier versions of Windows. Some of the functionality that was formerly accessed by using Web pages is now included in the client component. Therefore, this functionality has been removed from the updated certificate enrolment Web pages. Functionality that has been removed includes the following:
- Computer certificate enrolment: Administrative rights are required to request a computer certificate. In Windows Vista, Microsoft Internet Explorer does not use administrative rights to run. Therefore, the option to store a computer certificate in the computer store was removed from the Windows Server 2008 certificate enrolment pages.
The net result of this change is that it is no longer possible to request computer certificates and place them in the local computer certificate store using the web enrolment interface.
Consequently, you need to consider an alternative way of requesting certificates. Although it is possible to use the MMC with the Certificates snap-in (as covered in Adrian’s blog here) many certificate template enrolment permissions are based upon a user security context, as opposed to a computer context. Hence you need to start changing enrolment permissions by adding computer object permissions, which is not always ideal.
The remainder of this article is therefore split into the following sections:
- Preparing the Firewall Policy
- Generate, Submit and Install the Certificate Request
So, here goes…
Preparing the Firewall Policy
Rather than re-invent the wheel, it makes more sense to point readers to an existing article which covers the process of defining a firewall policy which allows certificate requests from the ISA Server computer itself.
The required firewall policy changes are covered very well in the Certificate Enrollment Requires a Custom Protocol blog entry by Stefaan Pouseele. The remainder of this blog entry assumes that you have successfully completed the firewall policy changes as described above (or in a similar fashion with a slightly more open policy).
Generating the Certificate Request
Assuming we have the required firewall policy in place, we can now concentrate on the actual certificate enrolment process. In order to perform this, we need to use the command line tool called certreq.exe. The first step in using this tool is to create an input file to define the required certificate properties.
Subject = "CN=<your-certificate-common-name>"
MachineKeySet = True
KeyLength = 2048
CertificateTemplate = WebServer
At this point, it is probably useful to explain some of the above entries in the input file for clarity:
The Subject parameter is used to define the actual common name of the certificate. Depending on certificate use, this would normally be the actual name of the ISA Server computer or the name that will be entered into a web browser if considering a web published application. Choose an appropriate entry for the <your-certificate-common-name> placeholder shown in the example above.
The MachineKeySet parameter is used to when you need to create certificates that are owned by the machine and not a user. You must set this key to TRUE if you are creating requests for domain controllers, a Web server, or any other service that runs in the machine’s security context. Hence in our example this is set to true.
The KeyLength parameter is used to define the length of the public and private key. Ultimately, the key length has an impact on the security level of the certificate. A Windows Server 2008 Web Server certificate template has a default key length requirement of 2048 bits, however our Windows Server 2003 client will default to 1024 bits. Therefore, we need to define a KeyLength of 2048 to avoid receiving a The public key does not meet the minimum size required by the specified certificate template 0x80094811 error.
The KeySpec parameter is used to define that the private key uses both encryption and signing (which is a standard TLS requirement).
The CertificateTemplate parameter is used to instruct the CA as to which certificate template should be used in processing the certificate request. The name must be specified as the common name of the certificate template or the object identifier of the template, not the template display name. Hence in our example this is WebServer.
Submit the Certificate Request
Once the above text file has been created in notepad (or similar text editor) it should be saved. In our example I have used isaserver.inf
Once saved, the next step is to use certreq to transform this file from an input file to a specific certificate request file. This is achieved using the following command:
certreq –new isaserver.inf isaserver.req
With the request file created, we can then submit the request to the CA using the following command:
certreq –submit isaserver.req isaserver.cer
|Please Note: Prior to submitting the certificate request, it is important to validate that the logged on user account has Read and Enroll certificate template permissions for the relevant certificate template. If not, these permissions must be added prior to submission. This whole process also assumes that the ISA Server computer is a member of the domain.|
Once you have entered this command, you will be prompted to select the issuing CA in the Select Certification Authority dialog box. Select the relevant CA for your environment, and then click OK.
When the certificate has been issued, you see a RequestId: <number> in the output results; this will be needed for the next step.
|Please Note: If your certificate template is configured with the CA certificate manager approval option enabled, it will be necessary to approve the certificate request (identified by the RequestID) using the Certificate Authority snap-in, before continuing.|
Install the Certificate Request
So, with the RequestID known, enter the following command:
certreq –retrieve <number> isaserver.cer
Finally, to install the certificate into the local computer certificate store, enter the following command:
certreq –accept isaserver.cer
The ISA Server computer is now provisioned with a certificate suitable for use on the web listener (and potentially other uses).
Please Note: If using ISA Server Enterprise Edition, it may be necessary to repeat the above process on all array members.
The above process is particularly useful when using a certificate template that has been configured with the Allow private key to be exported option disabled. In this scenario, the above process is ideal as it stores the certificate directly into the local computer certificate store, thereby negating the need for any form of export/import procedure. In addition, by changing the CertificateTemplate parameter in the certreq input file, it is also possible to request a different certificate use by defining a alternate template name.
So, there we go…hopefully this makes things a little easier and although the use of certreq looks a little daunting to those who haven’t used it before, it is actually quite simple in practice. This approach is also preferred by Microsoft, I believe ;)