More and more applications are beginning to include some form of Public Key Infrastructure (PKI) requirements as part of the core infrastructure dependencies. Based upon this drive, more customers are now beginning to consider PKI as a core infrastructure component in the same way as services like Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS) services. Therefore, having some form of PKI, or certificate service, is a growing need for most environments that I encounter. PKI is one those areas where it is perceived as a 'scary' technology area which contains a lot of new concepts for most people and a fair share of new acronyms to learn!
The aim of this blog entry is not to explain PKI concepts, but to provide detail about how to use ISA Server to protect one important aspect of any PKI implementation; namely external access to Certificate Revocation Lists (CRLs).
CRLs are a key foundation of most PKI implementations and serve a critical purpose of maintaining a list of all certificates that have been revoked. Unlike Active Directory, which is able to determine dynamically at logon point whether a user account has been disabled, a similar mechanism hadn't really existed in the PKI world until the introduction of the Online Certificate Status Protocol (OCSP), but this has not been available natively within Microsoft Certificate Services until Windows Server 2008.
The process of revoking a certificate is similar to disabling a user account, such that you are expressing that this entity is no longer trusted, and consequently cannot be used to authenticate, sign or be trusted for identification. In order for a user, client or application to validate that a certificate has not been revoked, and consequently is still a valid, trustworthy entity, it is necessary to contact an appropriate CRL to determine this.
Form an internal perspective, access to the CRLs is often overlooked as 'it just works', especially as most deployments will include some form of Active Directory integration which provide a CRL access method based upon LDAP. However, access to the CRL for Internet-connected systems is becoming increasingly more important.
Rather than re-invent the PKI wheel, I am going to rely on Microsoft's Windows Server System Reference Architecture (WSSRA) documentation to provide an excellent blueprint for a well designed PKI example that is based on Windows Server 2003 Certificate Services.
Looking at this design, it can be seen that access to CRLs for the 'Internet scenario' is fully supported and includes the following features:
- CRLs will be located on Web servers which are Internet facing.
- CRLs will be accessed using the HTTP retrieval protocol.
- CRLs will be accessed using an external URL of http://dp1.pki.contoso.com/pki
Please Note: To make things a little simpler for the purposes of this blog entry, and follow my own best practice, the URL used for CRLs will be changed to http://pki.msfirewall.org.uk/pki within the examples and walkthroughs.
So, based upon the above scenario we can now look at how to provide secure access to the CRL web servers using ISA Server. After all that talking, we can now get to the point of this blog entry, namely to provide an ISA Server web publishing walkthrough!
Using the ISA Server management console, select the Publish Web Sites task from the Firewall Policy Tasks pane.
Provide a suitable rule name, I have used Publish Certificate Revlocations Lists as shown below:Select Allow
Select Publish a single Web site of load balancer. Alternativelly, if you plan to have several web servers hosting the CRLs select the Publish a server farm of load balanced Web servers option.
Select Use non-secured connections to connect to the published Web server or server farm
In the Internal site name field, enter the Fully Qualified Domain Name(FQDN) of the web server that hosts the CRLs. If this name is not fully resolveable by ISA Server, you will need to add the correct computer name or IP address in the second input field.
At this stage, leave the Path (optional) input field blank; we will amend this part of the rule later.
Enter the external FQDN which will be included within the CRL field of issued certificates. Using the WSSRA example, this would be dp1.pki.contoso.com, however in our example this is pki.msfirewall.org.uk
On the Select Web Listener page, click New...
Enter an appropraite name for the web listener. I have used CRL Listener (Internet Anonymous)
Select Do not require SSL secured connections with clients
Tick the External network and then click Select IP Addresses...
Please Note: If you are using a Single Network Adapter ISA Server (unihomed) you will need to select the Internal network object, as opposed to the External network object.Select Specified IP addresses on the ISA Server computer in the selected network and then choose the appropriate available IP address followed by Add >
Select No Authentication from the drop down box.
Click Next when returned to the Select Web Listener page and ensure that the Web listener drop down box shows CRL Listener (Internet Anonymous) listener, or the alternate name used during creation. Select No delegation, and client cannot authenticate directly
Click Finish to complete the New Web Publishing Rule Wizard
Once complete, you should have a newly created rule in your Firewall Policy window.
Highlight the newly create rule and right-click to select Properties, followed by the Paths tab. As can be seen below, I have manully defined the Internal Path as /pki/* based upon the assumption that the pki virtual directory only contains CRL files.
However, if this is not the case, it is recommended to modify the paths entries to reference individual files, as opposed to all files in the pki virtual directory. An example of this is shown below using specific entries for the required CRL files.
Correcttion! - The internal path in the screenshot above should be /issuingca+.crl and not /issuingca.crl+. I will correct the screenshot in due course.
Both options will work equally as well, but in the event that the pki virtual directory contains files which you do not want to be published, then it is recommended to use specific file name entries to provide better security.
Once the paths entry has been defined, all that needs to be done is click OK and then apply the changes using the Apply button located above the firewall policy, to commit the new rule.
In order to test access to the CRLs, you can type the full CRL address directly into your web browser (e.g. http://pki.msfirewall.org.uk/pki/rootca.crl) and you should be prompted with an option to open or save the CRL file.
With a working rule in place, we will look at providing more advanced security in Part 2 with the addition of the HTTP filter, which I am quite keen on if you hadn't gathered by now!