Ssl – Wildcard certificate host name

httpsiis-8.5sslssl-certificatewindows-server-2012

We need to install a wildcard certificate (*.mydomain.com) onto our IIS 8.5 to secure the domain and all its subdomains of a website following a process similar to this.

When binding the certificate to the web site, considering we have many first level subdomains:

Web site 1 bindings (all http):
– www.mydomain.co.uk
– subdomain1.mydomain.co.uk
– subdomain2.mydomain.co.uk
– subdomain3.mydomain.co.uk
– ………….
Web site 2 (http):
– subdomain33.mydomain.com

Q1. What do we need to add in the Host name field for Web site 1 to secure its domain and all its subdomains, see below:

Q2. Can we bind the same wildcard certificate to another IIS website: Web site 2, which is another subdomain of the same domain (mydomain), just a different web site? What should we add in the Host name field in this case?

Q3: Considering we already have an SSL (single) certificate installed on the same machine/IP bound to a different domain web site, can the two SSL certificates coexist without conflicts?

Best Answer

A1. Whatever hostname you want this binding to listen out for

A2. Create your websites exactly as you would normally do for HTTP with host headers. As long as you use the exact same certificate (and it “matches” the host header), it’ll work.

A3. Depends on if the sites are on different IPs. If you need to run different sites on the one IP address (different host headers) and use different certificates, you’ll need SNI. If you can use the same wildcard cert, you don’t need SNI.

Related Solutions

SSL and domain masking

You'll find that "breaking SSL" for domains for which you don't have a certificate is a feature, not a bug.

If you want to have one certificate for multiple host names, there are two approaches:

wildcard certificates, but their usage is discouraged,
multiple Subject Alternative Names (one for each host) in the certificate.

If you can get a certificate for the number of domains you wish to mask, you may also be interested in doing the "URL masking" as a reverse HTTP proxy, locally on your server. This approach may also give you more flexibility if you need to expand to other domains with other certificates (provided you have multiple IP addresses or can use SNI, then).

Ssl – SNI and wildcard SSL certificates on the same server with IIS

Baris is right! The SSL certificate configured on an IP:PORT binding (example: 100.74.156.187:443) always takes precedence in http.sys! So the solution is as follows:

Do not configure an IP:443 binding for your wildcard-fallback-certificate but configure a *:443 binding (* means "All Unassigned") for it.

If you have configured your wildcard certificate on the Azure Cloud Service SSL endpoint (as i have) you have to change the SSL binding created by the Azure Cloud Service Runtime (IISconfigurator.exe) from IP:PORT to *:PORT. I am calling the following method in OnStart of my web role:

public static void UnbindDefaultSslBindingFromIp()
{
    Trace.TraceInformation(">> IISTenantManager: Unbind default SSL binding from IP");
    using (var serverManager = new Microsoft.Web.Administration.ServerManager())
    {
        try
        {
            var websiteName = string.Format("{0}_Web", Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.CurrentRoleInstance.Id);
            var site = serverManager.Sites[websiteName];
            var defaultSslBinding = site.Bindings.Single(b => b.IsIPPortHostBinding && b.Protocol == "https");
            defaultSslBinding.BindingInformation = string.Format("*:{0}:", defaultSslBinding.EndPoint.Port);
            serverManager.CommitChanges();
        }
        catch (Exception ex)
        {
            Trace.TraceError(ex.ToString());
        }
    }
}

The following screenshot shows a working configuration of our cloud service. Please don't be confused about the non-standard ports. The screenshot is from the emulated cloud service.

working IIS configuration

One further thing to mention: Do not change all bindings to * because the HTTP (port 80) binding only works with IP:PORT binding in the deployed cloud service. Something else is bind to IP:80 so *:80 does not work because * stands for "all unassigned" and the IP is already assigned somewhere else in http.sys.

Related Topic