What is SNI?

Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) protocol by which a client specifies which hostname (or domain name) it is attempting to connect to at the start of the TLS/SSL handshaking process. 

To understand what this definition actually means and how it works, let’s break it down into 3 parts. First, similar to TCP handshake, TLS handshakes also include IP address information as a way to locate the server which stores the TLS/SSL certificate. Second, it is not uncommon for one IP address (of one server) to be shared by 2 or more domain names. Third, SNI includes the hostname information in the TLS handshake (on Client Hello) in order to differentiate the domain names that share the same IP address (or that are on the same server). 

With SNI, servers (e.g. Apache, Nginx, or HAProxy) are now able to select the correct TLS certificate (of the requested website) among the multiple certificates stored in it. This consequently 1) enables secure (HTTPS) websites to have their own unique TLS certificates, even if they are on a shared IP address, and 2) allows multiple secure (HTTPS) websites (or any services over TLS) to be served by the same IP address without requiring all those websites to use the same TLS certificate. 

Without SNI, when multiple websites are hosted on one server (sharing the same IP address) and the server hosts several SSL certificates, the server may not be able to provide the correct TLS certificate when a client tries to connect to one of the websites through HTTPS. This may result in a “common name mismatch error” (meaning the name on the SSL certificate doesn’t match the name of the website), and your browser will show a message: “Your connection is not secure” or “your connection is not private”. OR worse, this may terminate the HTTPS connection, which will return a 502 status code (the reason for this is, the TLS handshake occurs before the client device indicates over HTTP which website it’s connecting to).

A good analogy for SNI is the home address in an apartment type building. Apartment type buildings host several rooms that function as individual residential houses. To deliver a package to a specific home address in an apartment type building, the address of the building is not enough, you also need to include the floor and room number. Just like the apartment type building, a server can host several domain names, so the IP address alone is not enough to indicate which SSL certificate to use when a user is trying to reach a specific domain.

Is it possible to use one TLS/SSL certificate for all domains stored in one server?

Yes. Multi-Domain TLS/SSL certificates can cover up to 200 domains in a single certificate. These domains are listed as Subject Alternative Names, or SANs, this is why Multi-domain certificates are also called SAN certificates. This type of TLS certificate can actually be used as an alternative solution to SNI, in fact, Multi-Domain SSL Certificates don’t have the disadvantages of compatibility issues with browsers or servers unlike SNI does. Here is the list of browsers and versions that support and don’t support SNI.

However, Multi-Domain TLS certificates have its own disadvantages as well:

  1. It’s visible who shares the same certificate. For companies that get their certificates from a hosting company, they usually use multi-domain certificates (usually DV certificates) for their customers. Some companies are not comfortable sharing the same certificate with their competitor/s. 
  2. 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. 
  3. The more domains added on the certificate, the bigger the certificate becomes. While the size hovers around several kilobytes, the certificate still needs to be downloaded before website content can be downloaded. This contributes to about several milliseconds of loading delay which has an effect on each engine rankings and even to user experience.
  4. Multi-Domain Certificates can’t support OV or EV certificates when shared between organisations. As mentioned in the hosting company scenario, all the domains from multiple companies are listed as SANs and are placed under one certificate, which is a DV certificate. Hence, the level of validation and associated trust is not that high.

SNI certificate or Multi-domain certificates?

While SNI and Multi-domain certificates kind of achieve the same thing, i.e. both can effectively provide SSL certificates to all domains under one server (having one IP address); SNI certificates use unique certificates for each domain, while Multi-domain certificates use just one certificate for many domains.

If you like to have a certificate having an OV or EV validation level, or you don’t like to share certificates with your competitors or other companies, then SNI certificate is the best solution for you. However, if you have important customers who are still using legacy browsers or operating systems and you don’t want to worry about compatibility issues, then Multi-domain certificates will be your best option.

In summary, SNI, or Multi-domain certificates, or their combination are suitable solutions to host certificates for your websites, when your website shares IP address with other websites.