IIS 7 and Above
Wildcard Subdomains on IIS 8 Leads to Wrong SSL Certificate for Other...
Last post Nov 11, 2019 04:11 AM by cyrussullivan
Nov 02, 2019 07:45 PM|cyrussullivan|LINK
I successfully configured a website using IIS 8 and Windows Server 2012 to support wildcard subdomains. Because IIS 8 does not support wildcard subdomain bindings (ex: *.example.com) I had to create a binding for the hostname * at the server's IP address
and I created an A record in the forward lookup zones for that domain with * as the host. I tried to enable SNI for the wildcard binding but I get an error that the * character is not supported by SNI.
This works great for hosting wildcard subdomains on the website that has the wildcard subdomains until I try to visit any other site on the server that uses SSL. In every case no matter what bindings I have for the other site and its SSL certificate,
IIS serves the SSL certificate for the domain that has the wildcard.
When I set this up I knew I was creating a catch all for the IP address on port 443 that would serve the specific domain for all requests not otherwise bound to a domain, but nowhere in any tutorial covering the matter was I ever warned about it negatively
impacting SSL for other domains. Every other domain has bindings clearly directing IIS to serve specific SSL certificates for those hostnames, but IIS is not recognizing that as an override of the SSL settings for the IP address.
How do I tell IIS not to serve the root IP's SSL certificate if exists a hostname for the domain that is being served where a different SSL certificate is bound?
Nov 02, 2019 08:56 PM|cyrussullivan|LINK
Solutions I have in mind for this if I can't find a way to do fix this using IIS are:
1. Buy a new Multi-Domain Wildcard SSL Certificate
Pros: I could secure every site on that IP with one certificate.
Cons: Cost, I have all the SSL certs that I would not otherwise need at the moment.
2. Use Windows Server 2016 and IIS 10
Pros: Supports wildcard subdomain bindings, would allow me to host my next project on the same IP since it will also include wildcard subdomains. Cost, I have found a host advertising a better package for slightly less.
Cons: Time and uncertainty. It takes time to migrate from a 2012 server to a 2016 server and I would be using a host that I have never worked with before. I have never done a migration like that that did not involve a lot of manual recreation of websites,
certificates, etc. but that might just be due to my own inexperience migrating stuff.
3. Get a Second IP Address
Pros: Would allow me to keep my current host and certificates.
Cons: My current host did not respond to my request. They just closed my ticket with no answer, which usually means they can't help me.
Right now I am leaning towards option 2 just because I think it is something I would probably need to do in a couple months anyway since I am not aware of any way to host multiple domains with wildcard subdomains on IIS 8.
Nov 02, 2019 10:42 PM|lextm|LINK
I wrote all technical details here https://docs.jexusmanager.com/tutorials/https-binding.html#background and you can also use netsh or Jexus Manager to carefully review your
Windows HTTP mappings. As long as you have the right mappings, it should work automatically. However, when you configured sites via IIS Manager, sometimes it generated wrong mappings.
Nov 04, 2019 06:40 AM|Yuk Ding|LINK
If you didn't set SNI flag for each IIS SSL binding, IIS would probably send Top site's wildcard certificate for other website.
So have you tried to bind your SSL certificate via command line "netsh http
add sslcert hostnameport=domain:port ……….."? You could check your ssl bining with command "netsh http show sslcert" then re-bind these certificate based on your requirement.
Now that Wildcard domain name is not supported in your server, is it acceptable to create multiple bindings header for each sub-domain?
Nov 11, 2019 04:11 AM|cyrussullivan|LINK
I moved to a new host that uses Windows Server 2016. That fixed the problem. Now I can use the IIS wildcard host name bindings to do this.