When a web client and a web server talk to each other over HTTPS, the very first thing that needs to happen is the secure handshake.
Here is a simplified example of such a handshake:
If this were HTTP and not HTTPS, the first thing the client would have sent would have been something like this:
GET /index.html HTTP/1.1
Host: example.com
This made multiple virtual hosts on a single IP address possible, since the server knows exactly what domain the client wants to access, namely example.com.
HTTPS is different. Like I said earlier, the handshake comes before everything else. If you look at the third step of the handshake illustrated above (Certificate), the server needs to present a certificate to the client as part of the handshake, but has no clue what domain name the client is trying to access. The only option the server has is to send the same certificate every time, its default certificate.
You could still set up virtual hosts on your web server, but the server would always send the same certificate to each client. If you tried to host both the example.com and example.org websites on your server, the server would always send the certificate for example.com when a client requests a HTTPS connection. So when a client requests example.org over an established HTTPS connection, this would happen:
This problem effectively limits the number of domains you can server over HTTPS to one per IP address.
The solution:
The easiest way to solve this problem is for the client to tell the server which domain it wants to access during the handshake. This way the server can serve up the correct certificate.
This is exactly what SNI, or Server Name Indication does.
With SNI, the client sends the server name it wants to access as part of the first message, the "Client Hello" step in the handshake diagram above.
Some older web browsers do not support SNI. For instance, on Windows XP there isn't a single version of Internet Explorer that has support for SNI. When accessing a resource over HTTPS on a server that makes use of SNI virtual hosts, you will be presented with a generic certificate, which may cause the browser to display a warning or error.
references:
https://serverfault.com/questions/109800/multiple-ssl-domains-on-the-same-ip-address-and-same-port
Here is a simplified example of such a handshake:
If this were HTTP and not HTTPS, the first thing the client would have sent would have been something like this:
GET /index.html HTTP/1.1
Host: example.com
This made multiple virtual hosts on a single IP address possible, since the server knows exactly what domain the client wants to access, namely example.com.
HTTPS is different. Like I said earlier, the handshake comes before everything else. If you look at the third step of the handshake illustrated above (Certificate), the server needs to present a certificate to the client as part of the handshake, but has no clue what domain name the client is trying to access. The only option the server has is to send the same certificate every time, its default certificate.
You could still set up virtual hosts on your web server, but the server would always send the same certificate to each client. If you tried to host both the example.com and example.org websites on your server, the server would always send the certificate for example.com when a client requests a HTTPS connection. So when a client requests example.org over an established HTTPS connection, this would happen:
This problem effectively limits the number of domains you can server over HTTPS to one per IP address.
The solution:
The easiest way to solve this problem is for the client to tell the server which domain it wants to access during the handshake. This way the server can serve up the correct certificate.
This is exactly what SNI, or Server Name Indication does.
With SNI, the client sends the server name it wants to access as part of the first message, the "Client Hello" step in the handshake diagram above.
Some older web browsers do not support SNI. For instance, on Windows XP there isn't a single version of Internet Explorer that has support for SNI. When accessing a resource over HTTPS on a server that makes use of SNI virtual hosts, you will be presented with a generic certificate, which may cause the browser to display a warning or error.
references:
https://serverfault.com/questions/109800/multiple-ssl-domains-on-the-same-ip-address-and-same-port
No comments:
Post a Comment