Jakub Anderwald

Microsoft released SSL diagnostics utility. I just found it mention in an article called Troubleshooting SSL in IIS. However, it has one drawback: it comes as installable MSI package.

If you don’t want to install anything on your server, just run a one-time scan of it, I created a ZIP package with just the executable files – you can just copy this to the server and run it. It contains both 32 and 64 bit versions in one archive.

SSL Diagnostics

Recently, when migrating an application that uses client certificate authentication to IIS 7, we noticed that ASP.NET impersonation stopped working.

Client was authenticated properly, but connection to database server was being established with machine account (DOMAIN\SERVERNAME$). We didn’t find any issue in the configuration, so we raised the case with Microsoft support.

It turns out one of IIS 7 / 7.5 default configuration files has a bug. The file is called C:\Windows\System32\inetsrv\config\schema\IIS_schema.xml, and under the following section there are wrong enum entries:

<sectionSchema name="system.webServer/security/authentication/iisClientCertificateMappingAuthentication">
<attribute name="logonMethod" type="enum" defaultValue="ClearText">
<enum name="Interactive" value="0" />
<enum name="Batch" value="1" />
<enum name="Network" value="2" />
<enum name="ClearText" value="3" />
</attribute>
</sectionSchema>

And that causes IIS to use wrong logonMethod when logging in with an impersonated certificate-mapped account. The correct values to be set there are:

<sectionSchema name="system.webServer/security/authentication/iisClientCertificateMappingAuthentication">
<attribute name="logonMethod" type="enum" defaultValue="ClearText">
<enum name="Interactive" value="2" />
<enum name="Batch" value="4" />
<enum name="Network" value="3" />
<enum name="ClearText" value="8" />
</attribute>
</sectionSchema>

We set logonMethod=ClearText but as the enum entry was originally ‘3’ this told IIS to actually use the Network Token method (the real value of ‘3’) – which does not allow for the authentication mechanism we require (i.e. Kerberos delegation to a service on another server). Changing the enums to their correct value resolved the issue.

Microsoft probably won’t release a fix for that, so you’ll have to update this schema file on your own.

Apart from the well-known authentication methods available in IIS:

• Anonymous
• Basic
• Digest
• Integrated Windows

you can enable Client Certificate mapping, to map users holding a specific certificate to a pre-defines user account. For some reason, this method is not alway mentioned in IIS documentation under “authentication” topic. It is, however, very useful for authenticating users across companies, or to grant access to applications – it’s hard to expect a service to type in its username and password.

You can enable all the authentication methods (including certificate mapping) independently. As you probably know, anonymous authentication “always wins” – if you enable it and any other authentication scheme, user will always come as anonymous.

The reason for that is how HTTP authentication is implemented. If an HTTP client, e.g. a web browser, requests a page that is part of a protected realm, the server responds with a 401 Unauthorized status code and includes a WWW-Authenticate header field in his response. This header field must contain at least one authentication challenge applicable to the requested page. Next, the client makes another request, this time including an Authentication header field which contains the client’s credentials applicable to the server’s authentication challenge. If the server accepts the credentials, it returns the requested page. Otherwise, it returns another 401 Unauthorized response to inform the client the authentication has failed.

If you enable anonymous authentication, client is not replied with 401 HTTP code, it gets the content instead – so it has no chance to provide the authentication information.

How does that relate to certificate client mapping? It’s different. Client certificate is sent by the browser with first request, without being asked for. This means – if you enable any “regular” authentication scheme and client certificate mapping, client certificate always wins. The first request will come with the certificate – so the web server will not responds with HTTP 401 and the WWW-Authenticate header.

If you want to do some tests, I recommend, as usual, the small but powerful WFetch tool. It can send any “generic” certificate to the web server or use a certificate you already have installed.

Just wanted to share one thing I noticed at work recently.

When you add a wildcard application map in IIS 5/6, there’s a checkbox called “Verify that file exists”. What it does is that it checks if the file called in URI actually exists on the file system before invoking the specified executable. If the file doesn’t exist, it will just throw HTTP 404.

This causes two issues:
1/ If you have an access control extension mapped like that (e.g. Siteminder), it will be possible to map your website structure without logging in – attacker can just iterate through all file names and find out which ones are there.
2/ If you have additional ISAPI filters mapped that reply to requests for files that are not on the hard drive, they will not be invoked. The first application mapping will reply to the request with HTTP 404. I had this case with Trace.axd file, which is served dynamically by ASP.NET. With the “Verify that file exists”, the request pipe was broken and it never made to ASP.NET