Here we are, with another of IIS 7.5 and Windows Server 2008 crazy bugs or features or I don’t know how to call them.
You have an intranet, with some internal websites. You want them in HTTPS, you have an internal Certificate Authority, so you create a certificate with the appropriate common name (equal to your internal domain). You load your certificate authority in Windows, you load your certificate in IIS, and SBAM!!! The result is this:
Sorry, I had to censor all IPs and domains, but you can notice the https binding without domain.
Why there isn’t a domain name in there??? Well maybe it does answer to https://test.domain.it anyway…let’s try it…mmmm…no. Well let’s remove the binding and add it again. Mmmmm….nope. Ok, I’ll ask to Mother Google.
After a lot of tries, I found this post: Brian Love – IIS and HTTPS binding with host header . It is not a solution, it is a workaround, an hack, but it works: you have to update your certificate friendly name to start with an asterisk.
Here are the steps:
- Start->Run->mmc-> press enter
- File->Add/Remove Snap-in
- Select Certificates -> Add
- A new window with snap-in options will open. Choose Computer Account -> Next -> Finish -> OK
- Browse the certificate tree to find your certificate – it will probably be under Console Root/Certificates (Local)/Personal/Certificates
- Right click on your certificate->Properties
- Write into the Friendly Name section *.YOURDOMAIN.COM . Replace yourdomain.com with your domain.
- Click OK
If you try to add your initial HTTPS binding, you will notice that it is now possible to edit the domain field.
Please note, you didn’t change at all your certificate, you just edited the name with which it is saved in windows archive. You should then note that your certificate didn’t became all of a sudden a wildcard certificate: this is just a hack to fool IIS to believe it is, so you can specify an host name.
IIS 7.5 choice to gray out hostname field when you specify a non-wildcard certificate is not entirely stupid. I may explain this topic better in another post, but anyway, extremely simplifying, in HTTPS the client first connects with destination server by IP, then encrypts the communication channel, then asks for the specific domain. The result of this behaviour is that the server cannot have more than one certificate per IP address and so one domain per IP (in HTTPS); if it had more than one, it wouldn’t have any way to choose between them. The exception is a wildcard certificate: the domain is in fact the same, so that’s ok. Notice: to avoid this problem, IIS 8 and newer use SNI (Wikipedia – Server Name Indication) to publish more than one domain in HTTPS on the same IP – but not all clients (read: browsers) are able to use it: some may simply not show the page.
IIS 7.5 manages this problem in this way: if the certificate isn’t a wildcard one, you simply cannot edit the Host Name field and it will be grayed out: the valid Host Name will be the one written in the Common Name field of the certificate. If it’s a wild card one, instead, you can edit the field.
The stupid thing here is that this behaviour isn’t managed using the Common Name field in the certificate (which you cannot edit without recreating the certificate), but using the Friendly Name used to save it in the windows archive – WHICH YOU CAN EDIT.
So it is simply made difficult, but in fact this is a useless check.