Work with client certificates for the ASP.NET MVC site on IIS 6

Question

Authentication using client certificates is required. I'm having some problems.

Some facts first

The whole site uses SSL. I am using IIS 6 (on Windows Server 2003) and have configured the site to accept client certificates without requiring them. Most browsers, however, are implemented in such a way that they will only ask the user for a certificate when it is strictly required. Because of this, the authentication model is not very useful.

Offers of my own

My first idea was to set the HttpResponse.Status property, but that requires an integer before the first space. The useful status for receiving a browser for sending a client certificate is 403.7 Client certificate required , so this will not work (if you cannot rewrite it).

I also thought that I would just configure IIS to require client certificates for certain paths, but this - from cource - only works with physical files, not routing.

A possible solution is to create a specific folder and require client certificates for it, which are more of a hack than a solution. Therefore, I would like to avoid this if someone has a better offer.

Explanation

I tested the response of Internet Explorer, Firefox, and Chrome (I use Chrome as the primary browser and Firefox as the secondary). None of the browsers request a client certificate if I - in IIS - did not configure it as needed.

The HTTP 403.7 status code is related to my understanding, since RFC 2616 only defines the status code as the first three digits. Since IIS 6 returns 403.7 when a client certificate is required, I thought sending it would force IIS to enable special mode that triggers the request.

I assume that the problem now is how to configure IIS for the required certficate based on the virtual path rather than the physical one.

Answer 1

There is no difference in the CertificateRequest message sent by the server when the certificate is simply requested and not required. The server makes the same request in both cases and simply stops shaking hands when the client cannot provide the required certificate. Thus, if your browser seems to be ignoring "requests", it should also ignore "requirements."

Check the following:

• Your browser is configured to ignore all certificate requests, never sending one?
• Your browser is configured to use this certificate without prompting User? (In other words, how do you know that the browser does not send the certificate?)
• Does your server really request a certificate?

The way I test this last case is OpenSSL (also available in Cygwin ):

 openssl s_client -connect server.y.com:443 -msg 

After the server sends its certificate message, it will add the CertificateRequest method, which is absent if it does not request client authentication. The output of s_client is as follows:

 <<< TLS 1.0 Handshake [length 0008], CertificateRequest 0d 00 00 04 01 01 00 00 

I'm not sure how this works if the server uses client authentication only on certain paths, as the initial SSL confirmation is completed before the client sends the HTTP request. It would be wise if the server requested a new handshake at this point, but I never tested to see which servers support this.

You can fake an HTTP request through s_client manually by typing:

 GET /your/path/here HTTP/1.1[Enter] Host: server.y.com:443[Enter] [Enter] 

If you never see the CertificateRequest message, your server is configured incorrectly.

Specifying directory-based security restrictions is fairly common and may actually simplify security administration. Do not be offended if this offers you a solution.

403.7 is not an HTTP status code. Is Microsoft "embracing, expanding and quenching" the trick? In any case, this does not seem to be in the right direction, since it is a transport layer problem, not an application layer problem.