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.

Fork us on Github

All the tests, including keys and certificates, are available on Github.
https://github.com/edvinanet/tls-o-matic
That's also where you will find all the current tests while waiting for us to write documentation here.

What is TLS?

"The TLS protocol provides communications security
over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery."
From RFC 5446 that defines the current TLS - version 1.2. Wikipedia is also a good help in explaining TLS.