Fiddling around with certificates is just as writing regular expressions; you do it just infrequently enough to forget the details and how you solved the problem at hand last time...
Problem
I recently needed to add a second website to an IIS7 server, giving me something like this:
- website1.domain.com (already setup, supporting both http+https bindings)
- website2.domain.com (new website)
I setup the new website2 to use the same ip and port binding as website1, but obviously with a separate host header.
Now I wanted to add a https binding to website2 as well. I specified the same wildcard certificate as website1 was using, but for some reason the Host name input field was disabled.
Without being able to specify a host header IIS naturally tells you "hey - you've already got a binding for that ip+port combo" if you try to start both websites at the same time.
I did not order or install the certificate on the server, but I knew it was a wildcard certificate, and I could see that it was issued to "*.domain.com" in the MMC Services snapin.
What the funk?!
I know I've solved this issue before... // recalling from tape
Solution
The solution or root cause if you will, showed to be the certificate's friendly name.
Even though the certificate was issued to "*.domain.com", the guy ordering the certificate from the CA specified "domain.com" as friendly name, and if the IIS7 Manger is told to use a certificate without a leading "*." as friendly name it will not recognize it as a wildcard cert, and hence disable the Host name input field.
So changing the friendly name of the certificate to "*.domain.com" was all it took .
(MMC Services snapin->double click the cert->details tab->edit properties)
