Access Denied: Configuring Certificates with IIS 5.0

When you follow best practice and keep your root CA offline, make sure to configure your CA so that it can find the CRL.

ITPro Today

April 13, 2003

3 Min Read
ITPro Today logo

Q: We're having a problem configuring Microsoft Internet Information Services (IIS) 5.0 to require client certificates. We're setting up a high-security Web site for our extranet, and we want to require client certificates that are distributed by our standalone root Certificate Authority (CA), a computer we'll keep offline for security purposes. In the lab, our test configuration worked great. We installed Certificate Services and IIS, set up our Web site, and configured the site to require client certificates that our CA signed. Then, we issued certificates to some test user accounts and successfully accessed the Web site from computers on which we'd installed a client certificate. In production, however, our clients can't access the Web site despite having a valid certificate. Instead, they receive a Forbidden error message. IIS logs only error 403,5 This error message indicates that the resource you are trying to access is secured with a 128-bit version of Secure Sockets Layer (SSL). In order to view this resource, you need a browser that supports this level of SSL. We're certain that the problem isn't 128-bit related. Any ideas about what's wrong?

Your Web server is trying to check the client's certificate against your CA's certificate revocation list (CRL) to make sure that the client hasn't been revoked. However, your Web server can't reach the CA to check the CRL because you follow best practice and keep your root CA offline. The configuration worked fine in the lab because you evidently left the CA running or perhaps installed it on the same computer as IIS, which was able to find the CRL.

You need to configure your CA so that its CRL is accessible to your IIS server. The client certificate's CRL Distribution Points field tells IIS in which folder to look for the CRL. By default, Certificate Services publishes its CRL in the CertEnroll folder, which is under the default Web site of the CA server's IIS installation. For example, the URL for Acme CA's CRL might be http://CA-Acme/CertEnroll/CA-Acme.crl. Whenever a CA issues a certificate, the CA puts http: and file: URLs into the CRL Distribution Points field.

One way to fix the problem is to copy the CRL from your CA to a folder on your IIS server (e.g., c:sys), then configure your CA to point to that location. To configure the CA to point to the CRL's new location, open the Microsoft Management Console (MMC) Certificate Services snap-in on your CA. Right-click your CA in the treeview pane, select Properties, then click the Policy Module tab. Click Configure, then click the X.509 Extensions tab, which Figure 1, page 9, shows. Remove all entries in the Locations list, then click Add CDP. Enter the path to the CRL's new location (e.g., file://c:sysca-acme.crl). Click OK, make sure your new location is selected in the Locations list, then click OK twice to close all dialog boxes. Reissue and install your client certificates; they should then be able to access the site.

By default, Certificate Services publishes a new CRL each week, so you'll need to either recopy your CRL to your IIS server each week or increase the CRL publication interval. To increase the publication interval, right-click the Revoked Certificates folder under your CA in the treeview pane, select Properties, and change your publication interval, as Figure 2 shows.

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like