Infralin's (not so) Frequently Asked
Certificates and its use in IIS6.0, ISA2004, etc
van der Linden ()
Infralin Consultancy (http://www.infralin.com)
Last updated: 26-10-2010
A computer certificate is required on the server when that server is to support SSL/TLS traffic. These Computer certificates should contain the private key.
Computer certificates are also known as server certificates.
Install the server certificate in the Personal container of the Computer Certificates MMC.
When installing a user or computer certificate always also install the Root and the Intermediate certificates higher in the certificate path.
The Root certificate should end up in the Trusted Root Certification Authorities container of the Computer Certificates MMC. The intermediate certificate(s) should end up in the Intermediate Certification Authorities container of the Computer Certificates MMC.
When installing another version of a certificate make sure to first delete the old version from all containers. This is especially relevant for (GlobalSign) root certificates where versions exist with different functionalities. When renewing a user or computer certificate this is not relevant.
Client certificates are used to authenticate users with their User Certificates against a server. In its simples form access is allowed as soon as the User Certificate is issued by a trusted Certificate Authority.
Client certificates can also be mapped to User accounts and through these User accounts used for specific authorization purposes.
The name Client certificates is used in this note to refer to User Certificates when used to authenticate users against a server. User certificates can also be used for other purposes, e.g. signing and encrypting E-mails.
Install the user certificate in the Personal container of the User Certificates MMC.
When installing a user certificate always install the root and the intermediate certificates higher in the certificate path as well.
The root certificate should end up in the Trusted Root Certification Authorities container of the Computer Certificates MMC. The intermediate certificate(s) should end up in the Intermediate Certification Authorities container of the Computer Certificates MMC.
When installing another version of a certificate make sure to delete the old version first from all containers. This is especially relevant for (GlobalSign) root certificates where versions exist with the same validity period and serial number but with different functionalities. Be aware that this does not apply to renewed certificates. A renewed certificate is another certificate, so could very well live next to the old certificate.
User certificates installed on the computer of the user should contain the private key. If a user certificate is installed on a server as a client certificate it should not contain the private key.
Use the Directory Security page of the properties of the web site involved.
Use the wizard behind the Server Certificate button to apply for and process a new certificate request, or to install an existing (exported) computer certificate certificate (typically in the form of a .pfx file).
If only SSL/TLS traffic is to be allowed use the Edit button on the Directory Security button either on web site or on Virtual Directory level.
Import the Computer certificate (typically in the form of a .pfx file) using the Certificates MMC for Computer Certificates (local computer) as described before.
Create a new or use an existing web listener.
Check the Enable SSL option on the Preferences page of the properties of this listener.
If only SSL/TLS traffic is to be allowed for this listener, uncheck the Enable HTTP option.
Use the Edit button on the Directory Security page of the properties of the web site or Virtual Directory involved.
Select Require Client Certificates.
Install the Root certificates of the certification authorities you would like to trust in the Trusted Root Certification Authorities container of the Computer Certificates MMC. Make sure the Root certificate supports the user authentication function.
Open the Preferences page of the properties of the Web listener involved.
Make sure Enable SSL is checked and a certificate is selected.
Press the Authentication button.
Check the SSL Certificate option.
Check the Require all users to authenticate option.
If you want to fallback to Basic Authentication in case no (valid) certificate is presented by the user, check the Basic Authentication option as well.
Certificates can be mapped to user accounts either on IIS or on Active Directory level. Mapping on Active Directory level is preferred and is the only option when using ISA.
In the Users and Computers MMC enable the advanced features (View / Advanced features).
Right-click the User account the certificate should be mapped to and select Name Mapings ….
Click Add and select the exported public User Certificate (typically a .cer file).
Check Use Subject to alternate security identity.
This maps an individual User certificate to an individual User account. You could also map all certificates of an Issuer to map to the same User account by un-checking this option.
To support certificate mapping on Active Directory level in IIS6.0 open the properties page of the Web Sites container in IIS (so not of an individual web site, but of the container above them).
Go to the Directory Security page and check Enable the Windows directory service mapper.
Open the properties page of the Web Site or Virtual Directory involved.
Go to the Directory Security page.
Check Enable client certificate mapping.
In case you would like to create certificate mappings on IIS level, leave the Windows directory service mapper unchecked and define your mappings through the Edit button of the Directory Security page of the Web Site or Virtual Directory involved. Be aware that you have to specify the password of the User account you are mapping to in that case.
Once SSL authentication is enabled, Active Directory level certificate mappings are available in ISA2004 automatically.
To restrict access to specific certificates only:
Include the users the certificates are mapped to in an ISA User Set (either directly or through an Active Directory security group).
Add this User Set in the Users page of the properties of the ISA rule involved, while removing the All Users User Set.
Be aware that if a certificate is not authorized, the rule does not apply and possibly other rules further down the list are tried.
As far as I know the certificate can in this case only be used to authorize the use of an ISA rule. It is not possible to pass the client certificate or the mapped user account on to the published IIS server. If that is required SSL tunneling should be used. When using SSL tunneling ISA cannot add much to the security unfortunately.
The traffic between ISA2004 and the internal IIS server can either be encrypted or not. If you want to encrypt this traffic the internal IIS server should have a Computer certificate and support SSL as described before.
The Server name specified on the To page of the properties of the ISA web publishing rule should in this case be the same as the name used for the certificate (otherwise you will get the HTTP 500 error).
This Computer certificate used for this internal traffic could be the same as the Computer certificate used by ISA2004 for the external traffic. In that case however the ISA2004 server should resolve the name of the certificate to the IP address of the internal IIS server, while on the Internet this name is resolved to the external IP address of the ISA server. If your DNS structure does not support this, it could be arranged through an entry in the Hosts file on the ISA server.
If the internal IIS server requires Client certificates, the ISA web publishing rule should be configured with a Client certificate on the Bridging page.
In most cases the Computer certificate installed on the ISA server can also act as a Client certificate. To support this role it has to be defined as a Service certificate of the Microsoft Firewall service though. To do so follow these steps:
Open the certificates MMC for Service Accounts (Run MMC / Add/Remove snap-in / Add / Certificates / Add / Service account / Local Computer / Microsoft Firewall / Finish / Close / OK)
Right-Click Certificates – Service / fwsrv\Personal / Certificates
Select All tasks / Import
Select the (private) certificate you would like to use (typically a .pfx file)
Enter the password used to secure this private certificate when exported.
Select Place all certificates in the following store
Click Next and Finish
If there is no need to have the certificate trusted by a well known certificate authority you can create a self signed certificate by using the IIS Resource kit command line utility SelfSSL.
selfssl.exe /N:CN=<domain name> /K:1024 /V:<validity in days> /S:<IIS web site ID> /P:443
The certificate is associated with the web site with the ID indicated. The web site ID of the default web site is 1. The web site ID of the other web sites can be found by looking at the folder name the log files of the specific web site are stored (the numeric part is the web site ID).
Wildcard certificates or certificates for multiple names can be constructed using for example:
The /P options sets the port number the web site specified in /S will use to listen for https requests. It is not stored in the certificate itself.
The certificate is stored in the Personal Certificates container of the local computer. It can be exported using the Computer Certificates MMC.