Wednesday, October 10, 2012

IIS Wildcard SSL Certificate Binding

Recently I had a customer who's HTTPS binding would only respond with HTTP 404 or HTTP 400 errors.  They were configuring HTTPS on their Default Web Site with a wildcard certificate as follows.

One of these things doesn't belong.
A quick curl test revealed a distinct difference between the HTTP and HTTPS bindings:

$ curl -vk http://www2.contoso.com/Login/Login.aspx >> /dev/null

< HTTP/1.1 200 OK
< Cache-Control: private
< Content-Type: text/html; charset=utf-8
< Server: Microsoft-IIS/7.5

$ curl -vk https://www2.contoso.com/Login/Login.aspx >> /dev/null

< HTTP/1.1 404 Not Found
< Content-Type: text/html; charset=us-ascii
< Server: Microsoft-HTTPAPI/2.0

You'll noted that the response headers included different responses from Server strings!  But what on earth is Microsoft-HTTPAPI/2.0?  A quick netstat reveals TCP 443 is bound to the System process at PID 4.  Isn't that the kernel or something?  Well, technically yes.  You see, the HTTP protocol in Windows is served from the http.sys driver (which is a hidden device in Device Manager).

It turns out that the way to avoid that server response is to remove the host name binding.  When IIS can't match the request to a binding, it dumps out at the driver level with the above HTTP 404 from Microsoft-HTTPAPI/2.0.

Lesson learned: if it isn't DNS, blame bindings.