Web sites has for a long time shared IPv4 addresses. On one single IPv4 address, one can run many sites. It wasn’t always so – it was only when a “Host:” header was added to HTTP the server could decide which web site to serve for a given request.
For TLS this did not work. The TLS negotiation, including the presentation of a server certificate with a host name, happens before the HTTP request is sent. It’s a chicken-and-egg problem. We can’t select a host with a HTTP header, since the HTTP request has not been sent when we start the TLS negotiation.
Introducing SNI, The Server Name Indication extension to TLS
In TLS 1.0 an extension called Server Name Indication, SNI, was introduced. With this, a TLS client can request a specific name in the TLS setup. The server, if it supports this extension, can select a certificate to present. With this solution, one IP address can be used for many TLS sites.
This extension works in IPv6 as well, but the need is not as big as every server gets a large amount of addresses and there’s no longer any shortage of addresses.
Test with three server certificates
The site in test #15 has three certificates. Which one you get depends on your request. The first one is used for all requests that doesn’t support SNI. The second and third one can only be reached by clients supporting the SNI extension.
- https://test15.tls-o-matic.com:415 Default server. You will always end up here if your client does not support TLS server name indication for test15a or test15b
All modern browsers support SNI. You should make sure that your HTTP client supports SNI.