Delta CRLs are Not Accessible via HTTP When Hosted on IIS

If you are running a Microsoft PKI in your environment then chances are you will have (or at least you should have) configured at least one HTTP based distribution point (CDP) for your Certificate Revocation Lists. If you are only publishing full CRLs then you will have no problems however if you are publishing Delta CRLs, the smaller, faster to process kind which list only certificates revoked since the last full publish then you may encounter an issue if you are using an IIS website to publish these.

The problem lies in the filename used for the CRLs. In my lab for example, my Certificate Authority issues a CRL file name rjglab-CA.crl and the delta files are named the same as the full CRL but they are appended with the plus character making the file name rjglab-CA+.crl. In it’s native configuration, IIS does not permit the use of the plus character because that character falls into the realms of IIS Request Mapping and the request handler.

HTTP Error Downloading Delta CRL

We can see in the screenshot above what the error code and message given by IIS is when we try to download the Delta CRL in the default configuration.

For an IIS webserver hosting your CRL and Delta CRL, we need to change the behaviour of IIS to allow this plus character to be permitted which luckily is easily done. First off, open IIS Manager on the server which is hosting and making available to clients your Delta CRL file. From the server home in IIS, open the Request Filtering page and from this page, select the Edit Feature Settings button in the Actions bar.

Request Filtering Settings in IIS

On the Edit Request Filtering Settings page under the General section, by default, Allow Double Escaping is disabled. Enable this option and then press OK.

Once you have made the change, try to download the Delta CRL file and you should find that the file is available and you can successfully download it.

Delta CRL Downloaded OK

Redirecting Non-HTTPS Traffic to HTTPS for SharePoint 2007

Like any sensible SharePoint 2007 deployment, I’m keeping the one I am working on currently currently strictly HTTPS (SSL). The reason for this is that we have opened up the SharePoint deployment to the web. Not a public facing web with anonymous access for internet users, but accessible without VPN on the web for our field employees to use.

One of the problems I have faced up until now is that when SharePoint is configured for HTTPS connections the Non-HTTPS connections are dropped and faced with a 404 Not Found error, the least helpful of all HTTP error codes.

Struggling for a solution to such a simple request –Redirect non-secured traffic to the secure protocol I searched online and found after a little digging this helpful article from a SharePoint blog at http://www.os.com/blog/capture-and-redirect-http-to-https-with-sharepoint-2007/. Here’s the crux of it:

  1. Configure the SharePoint AAM (Alternate Address Mapping) so that HTTPS is the default protocol for the public URL.
  2. Edit the IIS Site for SharePoint and either change the HTTP port to a random number, or do as I did and delete the binding for the HTTP port.
  3. Create a New IIS Site called SharePoint Redirect
  4. Assign the New Site to HTTP on Port 80
  5. Add a Host Header to the New Site Matching the URL of the Site (Eg. sharepoint.company.com)
  6. Using HTTP Redirects, Create a Permanent (HTTP 301) to the HTTPS URL of the SharePoint deployment.

Done

PS: Don’t forget to allow HTTP and HTTPS through the external firewall though otherwise users will never hit the redirect rule.