My company hosts about 10 domains, each on its own Web site and each with a unique host name (e.g., 1.domain.com, 2.domain.com). To secure logon and data-transfer procedures, we'd like to add a certificate to each Web site. The IIS documentation says that IIS 5.0 supports a feature called wildcard certificates, which would let us have a certificate that responds to *.domain.com so that we wouldn't need to purchase 10 separate certificates. We can create a certificate request with the common name *.domain.com and successfully install it on a Web site. However, when we attempt to use https://1.domain.com to access a Web site, we get the message The name of this certificate does not match the name on the site. IIS 5.0 supports this feature, so what's the problem?
This is one of IIS 5.0's mystery features. The IIS documentation refers to wildcard certificates as a supported feature, but they don't work until you install Service Pack 1 (SP1). However, although IIS 5.0 supports wildcard certificates, implementing the certificates is another matter. The IIS 5.0 Web Server Certificate Wizard doesn't support the asterisk (*) character in the domain name you enter in the Common Name field when you create the certificate request. So, how can you create a valid request for a wildcard certificate? The extent of my expertise ends here, but Thawte (http://www.thawte.com) has a solution. Thawte lets you purchase a wildcard certificate. You create a certificate request file with the Web Server Certificate Wizard, but you don't use "*" in your request. Thawte then somehow "fixes" the certificate request so that the wildcard portion works according to your requirements. However, for some reason, Thawte doesn't issue 128-bit wildcard certificates, and wildcard certificates won't work on IIS 4.0.
