Deploying on IIS with wildcard sites and certificates

Question
1

Hi

As a new forum member I’ve had to add an extra ‘.’ in my example domains, because the forum thinks I’m posting too many links! :blush:

In testing CertifyTheWeb (great product BTW), we have a problem with it deploying bindings for wildcard certificates on wildcard domain names. I’m using DNS validation which works great.

Our Windows Server 2012 is running a couple of website applications, which due to needing domain name wildcards (each client has their own sub-domain, e.g. client1.app1…com, client2.app1…com and client1.app2…com, and these can dynamically change), some of our bindings have to have a blank hostname for each IP address. Due to some specific sites having different requirements, the are some hostnames with specific bindings. Here are examples:

Site 1
IP 192.168.1.1:443, no hostname (so supports wildcard domain *.app1…com)

Site 2
IP 192.168.1.1:443, foo.app1…com (specific site with own configuration)

Site 3
IP 192.168.1.3:443, www.app1…com (specific site with own configuration)

Site 4
IP 192.168.1.2:443, no hostname (so supports wildcard domain *.app2…com)

The problem CertifyTheWeb has is that because sites 1 and 4 have bindings with no hostname, a certificate for either *.app1…com or *.app2…com tries to update both sites, which of course means IIS stops one of the sites, due to duplicate bindings.

I have tried various combinations of deployment, which end up with either both sites 1 and 4 getting the same binding, or only sites 2 and 3 get their correct bindings.

Whilst I appreciate the simplicity of the Deployment Mode options, it would be great to be able to select multiple individual sites as a deployment, then I could select sites 1, 2 & 3 for a one cert and then 4 for another cert.

Can you help me find a deployment config that works for wildcard domains?!

Thanks

2

Hmm, I need to think about this in a bit more detail. There was a concept of multiple deployments that never made it into 4.0 whereby you’d define the certificate once but have multiple ‘child’ managed certificates that can then go off and deploy/run script etc as required from that result. The problem with wildcards is you could literally have a hundred different uses for the cert including all manner of websites, ftp, mail etc.

As a workaround you could use a post-request script (Show Advanced Options) and script the other (non-hostname specif) binding updates (really just setting the cert thumprint on existing bindings). However one IP cannot have two cert bindings on Windows.

Note that unless you need to support non-SNI capable clients (like Windows XP) you should avoid IP specific bindings as much as possible - they used to be required pre-server 2012 but with SNI it’s no longer mandatory to map SSL cert to specific certs.

On Windows there can be only one IP specific certificate binding per cert/IP/port combination (SNI bindings using */All Unassigned for the IP address) and if you allocate a cert to an IP that cert will be used by windows in preference to any other binding you attempt to create, this often results in websites serving the wrong cert (because they share the IP with another site).

My advice is don’t use default blank hostname bindings or IP specific https bindings if you can avoid them.

3

Many thanks for you response and appreciate the thoughts. I’ll look into post-request scripts, although I have little experience in PowerShell.

I can use SNI for the sub-domain specific sites, and I did try this–for the sites with hostnames in the bindings it works really well–I guess this is more the target audience for CertifyTheWeb?

The problem is still that for wildcard domain sites on separate IPs, there has to be no hostname in the bindings, and CertifyTheWeb does not treat them differently–this is why it would be good to be able to select specific IIS sites in the deployment mode for a cert.

4

While composing my previous reply, I was also looking at scripting and could do the following in a post-hook script:

param($result)
netsh http delete sslcert ipport=“192.168.1.1:443”
$guid = [guid]::NewGuid().ToString(“B”)
netsh http add sslcert ipport=“192.168.1.1:443” certhash=$result.ManagedItem.CertificateThumbprintHash certstorename=MY appid="$guid"

This deletes the cert from the IP:port binding and then adds the new one back in–I’ll let you know how it works.

1 Like
5

Thanks, also worth noting is that you can configure Deployment to be ‘update only’ for bindings, so it doesn’t add any new ones. That way once you have your certs you can configure https bindings as you like in IIS, then get updates to match on certificate thumbprint only (so if the old cert was being used then replace with the new cert). This is useful for binding edge cases.

6

After the original auto deployment didn’t quite work for me and I manually adjusted the bindings and certs, I did try the ‘update only’ option, as I thought this was the answer.

Unfortunately, if I select ‘Update existing https bindings only’ and tick ‘Binding hostname not specified (IP only or All Unassigned)’, the preview shows it picking up both of my ‘not specified’ sites and with an Add action, even though they have different certificates (on different IPs). Is this a bug?

7

Thanks, I’ll investigate that. If it’s offering to Add a binding when you’ve chosen ‘Update only’ that’s definite bug.

8

I’m trying that script, but my binding looks to have been deleted, but not created. Do you still have something like this going? I can run the netsh manually and get what I need, but that is obviously not ideal.

9

@ragingtryrant this thread is ancient, please start a new thread describing the problem you are seeing in detail, providing info on what you have and what you’re trying to do. In general there is absolutely no need for any scripting related to IIS because Certify handles all the binding updates automatically.