A few weeks ago, we run into a strange problem. We were in the middle of our Let’s Encrypt rollout, in which we create a dedicated certificate for each of our domains. Since we run multiple domains on a single web server with only one IP address, we need to activate SNI (Server Name Indication). That worked on all our servers – expect one. That server gave us this useless error page:
There was no log message from our application, no IIS log and no entry in the Event Viewer. Absolutely nothing.
We checked every setting, restarted the server and then IIS, but all looked as it should and was using the same configuration we had on all our other sites. We could reproduce this problem on the test system; therefore, it was not something machine-specific.
After a long bug hunt, we found the difference: This was the only site we run on HTTP. Every other site runs on HTTPS and works without any problems.
Conclusion: Don’t mix SNI with HTTP
In theory, SNI should only affect HTTPS sites and the HTTP site should run without a problem. On port 80 using HTTP the concept of Virtual Hosting should work as always and deliver the right HTTP site.
Unfortunately, we could not find anyone else with the same problem or a solution to get everything working. If you have a solution, please post a comment at the end of this post.
Workaround 1: Only one domain on this server
We settled with only running one domain on this site. Our HTTP and HTTPS site have the same domain name and with only one domain on the server, we do not need SNI.
We could stop the other web site that was running on the same machine. You may not be able to do that, but maybe you can move those sites to a different web server.
Workaround 2: Only one certificate for all domains on this server
Another approach to bypassing SNI is to use a wildcard or a Subject Alternative Name (SAN) certificate. While a wildcard certificate allows you to use one certificate for all subdomains (*.domain.com), a SAN certificate can contain various domain names. Let’s Encrypt supports both types of certificates (check the FAQ).
We used this approach on another server that runs IIS 7.5 and does not support SNI. For me this is the preferred approach whenever SNI is not an option.
Lessons learned
Even when there should absolutely no interference between two concepts, test if this is really true. HTTP should not be influenced by SNI, yet it was and our production site had an unnecessary incident. Therefore, check and double-check if all sites work and do not forget the odd site that runs on the same box using a different protocol.