Started to notice this today, nothing besides a default setup with the bot, which reported no issues. It isn’t an issue, the websites work on https just fine. Just curious as to why I get this, well, rather … can I address this?
Please fill out the fields below so we can help you better.
My domain is: n/a
I ran this command: tail -F /var/log/apache2/error.log
It produced this output: [ssl:warn] [pid 11898] AH02292: Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
My operating system is (include version): Ubuntu 14.x lts server
My web server is (include version): Apache/2.4.7
My hosting provider, if applicable, is: n/a
I can login to a root shell on my machine (yes or no, or I don’t know): su
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no
My summary would be that SNI is the way a server, with multiple hosts on a single IP address, links the “browser” or “client” to the correct pages. If the “client” or “browser” that is used is a really old one, and doesn’t support SNI, then that user will get the default site for your IP address, not necessarily the one they were after.
Thank you for the response, if what you are saying is that if someone goes to the IP, that’s when this is potentially triggered? I do not really wish people to do that. They get the hosts. The IP is probably only used by bots and scripts or curious pokers. There is indeed one IP, multiple hosts. Nothing I can do about it, they don’t really give that many unique dedicated IPs to people much anymore these days. I doubt ‘this’ is a valid reason to provide another handful. I’ve rDNS the IP to the main host. The rest are virtual hosts I guess. I will ignore the warning msg.
Computers generally use IP addresses, rather than host names. So when an old browser goes to "yourdomain.com" it checks with the DNS servers what the IP address for "yourdomain.com" is and asks for the data. If this is an old version of windows XP for example, then it will just ask for the data from that IP address. More recent browsers will ask for the https data from that IP with and additional parameter - SNI - asking for data from "yourdomain.com"
In other words - anyone on an old browser, may not be able to use your site via https - which will be true of all sites on shared IP's.
Okay, my train of thought was in a different box, thank you for clearing it up. it makes so much sense now. I in the meantime also read up on the link you gave me. Which really helped. Thumbsup.
IIRC, you can also run into issues with certificates and server configuration as well. Let’s say you have a webserver hosting 2 domains on 2 different IP addresses - I think the clients will need to support SNI if a single certificate is used for both domains (ie, using the Subject Alternate Names); but wouldn’t need to support SNI if a unique and single-domain certificate is used for each domain.
When using two separate IP's you can ignore hostnames altogether: SNI isn't of any use than.
When you've got just one certificate for both domains, SNI isn't strictly needed too: SNI is just for the server to select the right vhost before choosing a certificate. When just one certificate is used, the server could select the vhost after the TLS session has been set up, with aid of the HTTP Host header: shouln't really need SNI for that..
The need for SNI exists before the TLS session is set up and before a certificate has to be chosen: the server doesn't have the HTTP Host header yet, but does have to choose between two certificates before he can receive a Host header.. How? Through SNI! SNI sends the host unencrypted, so the server can choose the apropriate certificate.
The problem I'm talking about -- perhaps poorly worded -- is that the clients which do not implement SNI, will not (usually) accept certificates that have the requested domain name in the SubjectAltNames instead of CommonName. This is not about the tech specs of SNI, but of the behavior of clients who implement SNI vs those that don't.
IIRC, while non-SNI clients will be able to request the right domain from the server -- since the server only does one domain -- they won't necessarily accept the served certificate as valid because they may only look at the Common Name... so the best way to handle those clients was to configure the server to serve a unique cert for each domain using the Common Name.
In terms of web browser, support for SANs is even more widespread that support for SNI, which itself is now almost universal. Looking at the Common Name for things like DNS names or IP addresses has been deprecated for PKIX (the Web’s Public Key Infrastructure) for seventeen years. Firefox didn’t exist when this was established. It’s from the era when Internet Explorer 5 was hot stuff and people were getting paid to fix two digit date fields in COBOL code.