If you have shared host or a cloud or virtual or dedicated server or service hosting multiple domains, it is normal to face the message – This site works only in browsers with SNI support. It’s not an error, it’s a warning message. It is a thing related to IPv4 and initial days with TLS. We are trying to explain the implication of the error message and in very short, for ordinary websites like a personal website such error in general has no negative impact. Such if happened with this website it would be not perfect – a running blog with ads needs a dedicated IP. Number of IPv4 is limited and IPv6 unfortunately not so much popular yet. You have to tolerate the message for not so very important things for next one decade or so.
Explained : This site works only in browsers with SNI support
SNI is a feature extension of TLS. SNI stands for server name indication. On IPv4, one IP on a server like this IP 31.14.136.224 normally opens one domain. If single server has multiple domains then obviously IP logically should open one website. While creating a TLS connection, the client (read browser) requests a certificate from the web server with one IP. When the web server sends the certificate, the client examines it and compares the name it was trying to connect with the names included in the certificate. If a match occurs, the connection is normally proceed. If match is not found, user may be warned of the mismatch as it can be a try to run man-in-the-middle attack.
In name-based virtual hosting, we host multiple domains on a single web server with one IP address. While using HTTPS, the TLS handshake happens before the server sees any HTTP headers. It is not possible for the server send information in the HTTP host header to decide which certificate to present from the same IP address.
Server With SNI, you can enable multiple SSL certificates on a single IP. It is true that you can create two or more https sites on a VPS with only one IP address.
---
Is the message “This site works only in browsers with SNI support” can be fixed?
Almost no. But most modern operating system and sane browsers will not show error. That thing is fixed from servers, browsers etc by patching. Fixing means the usage of available patches which allow such usage :
1 | https://tools.ietf.org/html/rfc6066 |
If you run cURL against your one multiple domain on a single IP:
1 | curl -I https://abhishekghosh.pro |
and receive no error, it simply means that the thing is correct.
Security Concerns
This command will not return error (replace with own domain with one IP multiple domains) :
1 | curl -I https://abhishekghosh.pro |
but this will return error (replace with own domain with one IP multiple domains) :
1 | openssl s_client -connect abhishekghosh.pro:443 |
Try this, you’ll get no error (replace with own domain with one IP one domain) :
1 | openssl s_client -connect thecustomizewindows.com:443 |
These kind of bug of security exploit is not uncommon with SNI :
1 2 | http://www.cvedetails.com/cve/CVE-2013-4508/ https://nvd.nist.gov/vuln/detail/CVE-2013-4508 |
On a non-SNI-based web server set-up multiple domain configuration with one IP would not work. There is Apache2 directive to set whether a non-SNI client is allowed to access a name-based virtual host or not. This configuration will make SNI support to force the SNI supporting browsers to allow the website :
1 2 3 4 5 6 7 8 9 | Listen 443 NameVirtualHost *:443 SSLStrictSNIVHostCheck off <VirtualHost *:443> DocumentRoot /www/var/html ServerName www.example.com ... ... </VirtualHost> |
Default is off, hence the directive not needed. But for one server one IP setup, this is more secure :
1 2 3 4 5 6 7 8 9 | Listen 443 NameVirtualHost *:443 SSLStrictSNIVHostCheck on <VirtualHost *:443> DocumentRoot /www/var/html ServerName www.example.org ... ... </VirtualHost> |
But it can wrongly block legit visitors. There are more funny stories around making the SSLStrictSNIVHostCheck on interesting :
1 | https://www.mnot.net/blog/2014/05/09/if_you_can_read_this_youre_sniing |
Inference is – for a very secured subdomain of your website, you can take the risk to use SSLStrictSNIVHostCheck on for single server single IP setup.
