While looking at PKIView for a newly installed CA, I noticed that the delta crl (CAName+.crl) was "Unable to download", despite the file being present in the CDP virtual directory file location. When I copied the URL and browsed to the location, I received an HTTP Error 404.11 -- URL Double Escape error.

 

This is apparently a new security feature under IIS 7.0 that denies double escape characters in the URL. Not sure what "escape characters" are, but I presume that a space and then the + sign were the characters in my URL.

 

Fortunately the Error page gave some insight about changing the application.config or web.config file. A quick search on Google led me to a Microsoft KB article that helped to point me in the right direction: Error message when you visit a Web site that is hosted on IIS 7.0: "HTTP Error 404.11 – URL_DOUBLE_ESCAPED"

 

This article instructs you to change the application.config file by modifying the allowDoubleEscaping property to True. In looking at the application.config file there was a section for each of the virtual directories under the website, except for the CDP virtual directory. All of those sections had their allowDoubleEscaping attribute set to true, so I had code examples to build the xml for the missing section. I did notice however that the CDP file location did have a web.config file, which had a sparse section of xml code specifically for the CDP virtual directory. And this the web.config file is what I actually modified to fix the 404.11 error.

 

I added a security section under configuration/system.webserver.

         <security>
                <requestFiltering allowDoubleEscaping="true" />
        </security>

 

Original File:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <directoryBrowse enabled="true" />
    </system.webServer>
</configuration>

 

Modified file:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <directoryBrowse enabled="true" />
         <security>
                <requestFiltering allowDoubleEscaping="true" />
        </security>

    </system.webServer>
</configuration>

 

This fixed the issue!

Just had an interesting issue with a new 2008 PKI implementation: My certificate templates were not showing up for Web Enrollement.

 

I had just set up a complete PKI using AD CS 2008 and was trying to issue certificates to a Gateway SCOM server in the "Other" Forest and to the Management server in the home forest. And of course, I ran into some interesting issues.

 

For security reasons, none of the default templates were published when the CA was turned up, this was to ensure that someone had to actively approve the publishing of a certificate template and to prevent the auto-enrollment of certificates until the organization was explicitly ready. This unique situation would complicate troubleshooting.

 

So the first template to be published was the newly created SCOM Certificate template. Now there was nothing special about this template. It is simply a Computer template (with the Server and Client Authentication OIDs, just like the default Computer template). Instead of publishing the default Computer template, I duplicated it and extended its life to 2 years, but when I did this it asked me if I wanted to make this a 2003 or a 2008 version. Well, hell yeah, I want 2008. Why else did I go throught the trouble of deploying 2008 CA's -- (ummm, maybe not!!).

 

This answer had the effect of adding advanced features to the version 3 certificate, something that I wasn't fully aware of at that time, which I discovered hours later  can not be web enrolled. 

 

This of course presents a challenge to a SCOM Gateway server in the "Other" forest, because that is the only method that it has of connecting to the issuing CA in the home forest. (Sure, I could have used a third party manual request generation tool, but I was irked that this wasn't working!!!).

 

So after a few hours of verifying permissions and settings, I ran across the fact that V3 certificates cannot be webenrolled and the fact that Authenticated Users in the Root Domain does not translate to computers or users in sub-domains.