Just finished provisioning a new SSL certificate for Oakton’s Dev environment and was having a bit of trouble getting it set up properly. Essentially you can buy an SSL Cert for as many servers as you want, for as many sub-domains as you want. Some are better than others – GoDaddy are one of the cheapest, but we’ve gone with GeoTrust’s RapidSSL as it can all be managed through the same domain registrar (GeoTrust is owned by Verisign).
Anyhoo, the reason for this entry is to highlight the fact that there appears to be a level of misinformation out there on setting up wildcard DNS entries. Historically, you could only ever buy an SSL Cert for a specific domain (e.g. secure.mydomain.com) – as such, when you tried to apply the same cert to shopping.mydomain.com, it came up with nasty “certificate and domain do not match” error messages in your browser, etc.
In order for IIS 7 Management Console to be user friendly, if you are using a normal SSL Certificate (registered for a specific site) it will let you select the cert – but will not let you set the Host Header. This kinda sucks, because in SharePoint you have My Site and the SharePoint site on different IIS Sites – the idea behind a Wildcard Cert is that you can use the same cert to secure traffic between both sites without having to buy 2 of them (one for each site).
However… When you load the certificate into the server, you get asked for a “Friendly Name” – Which is where you put Something like “The Online Banking certificate for MyDomain.com” – but if you are implementing a wildcard Cert, you need to put the FQDN that you used to register it, including the * – so by putting in *.mydomain.com you can then modify the host header Bindings and have the HTTPS traffic routed to the relevant site the same way HTTP works.