Note: You may notice, we’re using the technically correct term of TLS Certificate here instead of SSL because TLS protocols, the successor to SSL, are actually what’s in use today. For more explanation, see our post on TLS vs. SSL.
Server Name Indication (SNI) allows the server to safely host multiple TLS Certificates for multiple sites, all under a single IP address. It adds the hostname of the server (website) in the TLS handshake as an extension in the CLIENT HELLO message. This way the server knows which website to present when using shared IPs. Typically, companies that use shared IPs under one server are hosting companies and they face the everyday problem: ‘how do I get my server to select and present the correct certificate?’
Here’s a closer look at the problem. On an HTTP site, a server uses HTTP HOST headers to determine which HTTP website it should present. However, when using TLS (the protocol behind HTTPS), the secure session needs to be created before the HTTP session can be established and until then, no host header is available.
So here’s the dilemma: with HTTPS, that TLS handshake in the browser can’t be completed without a TLS Certificate in the first place, but the server doesn’t know which certificate to present, because it can’t access the host header.
What Is SNI and How Can It Help?
Server Name Indication (SNI) is an extension of the TLS protocol. The client specifies which hostname they want to connect to using the SNI extension in the TLS handshake. This allows a server (for example Apache, Nginx, or a load balancer such as HAProxy) to select the corresponding private key and certificate chain that are required to establish the connection from a list or database while hosting all certificates on a single IP address.
When SNI is used, the hostname of the server is included in the TLS handshake, which enables HTTPS websites to have unique TLS Certificates, even if they are on a shared IP address.
You may wonder why this is so important. Why do we need a way to support unique certificates for shared IPs?
The Dilemma of IPv4 Shortage
The Internet Protocol version 4 (IPv4) has roughly 4 billion IP addresses. But, there are already more than 4 billion internet connected computers worldwide, so we are facing a shortage of IPv4 addresses. The Internet Protocol version 6 (IPv6) should fix this problem, offering trillions of addresses, but there is still some existing network equipment that does not support IPv6. It is estimated that 90% of common operating systems for mobile phones, PCs and servers can support IPv6. So we’re getting very close to fully supporting IPv6, but for the few legacy systems that still require shared IPs, a dual approach might have to be adopted - SNI for IPv4 for the few legacy browsers, and unique IPs for all domains via IPv6 for the rest.
How SNI Can Help You and Solve the IPv4 Shortage
With SNI, the server can safely host multiple TLS Certificates for multiple sites, all under one single IP address.
That way, fewer IP addresses are needed and used, making IP addresses more available. While we will eventually run out of IPv4 addresses, the process is slowed down and gives people more time to update to compatible browsers, routers and servers.
SNI also makes it a lot easier to configure and manage multiple websites, as they can all point to the same IP address. Besides that, it has the advantage that simply scanning an IP address doesn’t reveal the certificate, which adds to the general security.
Are There Any Disadvantages to SNI?
It is clear that SNI is a great solution for shared IPs, but there is one small remaining disadvantage; it only affects a very small proportion of internet users – those who use legacy browsers or operating systems.
SNI is not supported in legacy browsers and web servers. Modern browsers (generally less than 6 years old) can all handle SNI well, but the two biggest legacy browsers that struggle with SNI are Internet Explorer on Windows XP (or older, which is estimated to have been used to access websites by 3.18% of users in April 2018) and Android 2.3 and older (used by around 0.3% of Android users). If the legacy browser or OS doesn’t support SNI, the handshake will choose the default certificate, which can lead to a common name mismatch error.
Usage of XP and Android pre-2.3 will continue to fall and therefore the compatibility issues will become less and less important. It’s also good to remember that Windows XP doesn’t support TLS 1.1 or TLS 1.2 and with the upcoming PCI requirements, users won’t be able to visit many sites anymore anyway.
Usage of these browsers is in decline and will continue to be, but it means that a percentage of web users will currently still struggle receiving a HTTPS website, if it is delivered via SNI.
There is a full list of browsers and versions that support and don’t support SNI here.
One way to get around this issue is to use Multi-Domain TLS as the default certificate so that you can list all the domains on the shared IP in one certificate (more on this below).
Another aspect to point out about SNI is that the connection starts unencrypted in TLS 1.2, which exposes clients to censorship and surveillance. TLS 1.3 has solved this issue, but isn’t quite fully supported yet so make sure you are ready to jump on TLS 1.3 as soon as it becomes widely adopted.
These challenges are certainly not enough to degrade the beauty of SNI. We recommend you use SNI wherever you can.
The Differences between SNI and SANs
A Multi-Domain Certificate (sometimes referred to as a SAN Certificate) is another way to deal with the IPv4 exhaustion. Multi-Domain TLS Certificates don’t have the disadvantages of compatibility with browsers or servers like SNI does. They work like any other TLS Certificate and cover up to 200 domains in a single certificate. SNI, on the other hand, can easily host millions of domains on the same IP address.
Why don’t we just use Multi-Domain Certificates then?
On a Multi-Domain Certificate all domains need to be added to the one certificate. These domains are listed as Subject Alternative Names, or SANs. If a SAN needs to be added or removed, or a certificate needs to be revoked or renewed, the certificate needs to be replaced and redeployed for all domains. It’s also visible who shares the same certificate. For companies that get their certificates from a hosting company, for example, that uses Multi-Domain Certificates for their customers, that company might not be best pleased to share a certificate with its competitor.
It also makes the certificate bigger, and the more names are added, the bigger the certificate becomes. While we are just talking about kilobytes, this information needs to be downloaded before anything else on the sites can be downloaded. Essentially, it blocks the site from being loaded for one or more milliseconds depending on the internet connection – not a big delay by any means, but when competition to rank in Google is tight, a few milliseconds on page load speed could mean a lot.
Another important downside is that Multi-Domain Certificates can’t support OV (Organization Validated) or EV (Extended Validation) SANs when shared between organisations. For example, in the earlier mentioned hosting company scenario with domains from multiple companies listed as SANs under one certificate, those domains would be DV (Domain Validated) level. These validation levels refer to the amount of information that is verified before the certificate is issued. DV means the site owner demonstrated administrative control over the domain, while OV and EV also verify information about the site owner’s identity (e.g. legal and operational existence).
Well-known users of Multi-Domain certificates include Cloudflare and Google. Google is only using it for older clients that don’t support SNI.
Should I Use SNI or Multi-Domain Certificates?
Overall, while SNI and Multi-Domain Certificates achieve the same thing – namely reducing the amount of IPv4 addresses needed – they achieve this in an opposite kind of way:
SNI means you can have unique certificates for each domain (i.e. many certificates) while those domains share the same IP. Multi-Domain Certificates, on the other hand, simply use one certificate for many domains, which in return also means one IP for many domains.
It becomes clear that there is a place for both SNI and Multi-Domain Certificates– either on their own or in combination. With these solutions, you can continue to host certificates for customers without needing to worry about dedicated IP addresses or compatibility.
If you would like to speak to GlobalSign about a solution that is right for you, get in touch with us today.
