What is SNI or Server Name Indication – Explained with an Example

In the world of TLS, Server Name Indication or SNI is a feature that allows clients (aka your web browser) to communicate the hostname of the site to the shared server. It’s in essence similar to the “Host” header in a plain HTTP request. However, when using TLS, the secure session needs to be established before the HTTP session, which means the server does not see the “Host” header until later in the communication process.  Consider the following example:

Todd wants to host more than one site on a virtual server. Why on earth would he want to do that? Because no one has an unlimited supply of IP addresses when it comes to IPv4 (which only has around 4 billion IP addresses to go around). According to the Global Digital 2019 report, there are 4.39 billion internet users in 2019 (do the math!) SNI facilitates using fewer IP addresses, giving us more time to switch to IPv6 before we eventually run out of IPv4 addresses.

Todd understands that if there is any confusion between the resource requested by the client (let’s say site2.com) and the certificate sent back by the server (assume that the default certificate it sends back is certificate 1 that belongs to site1.com), the encrypted connection will fail to get established and that would have a direct impact on his business. So, what does Todd do? He learns about SNI, where the client can tell the server exactly which certificate it is requesting.

How does SNI work?

SNI is an extension of the TLS handshake where the client hello uses the SNI field to specify the hostname to which it wants to connect. The server can then parse this request and send back the relevant certificate to complete the encrypted connection. This certificate includes the name of the server to which the client is connecting (common name and subject alternative name) and if a match occurs the connection proceeds or in case of a mismatch it may be aborted to prevent a possible man in the middle attack.

Before SNI came into our lives, if Todd wanted to host three websites with different SSL certificates, he would have had to purchase three IP addresses, one for each site. Not only would this cost Todd additional money but also expedite the decline in the number of available IPv4 addresses.

When it comes to the question of scalability, more than 98% of clients requesting HTTPS-enabled sites support SNI. Older operating systems like Windows XP do not support TLS 1.1 or 1.2, and only a small proportion of internet users who still rely on legacy browsers (like IE on Windows XP or Android 2.3 and older) would be unable to utilize SNI.  A multi-domain (SAN) SSL certificate is an alternative that serves as a workaround for the problem of browser incompatibility arising with SNI on legacy systems.

What is the difference between SNI and SAN SSL certificates?

Overall, both SNI and multi-domain (also called UCC/SAN) certificates can have a similar functionality – reducing the number of IP addresses required. They achieve so in two different ways. 

On the one hand, we have multi-domain certificates utilizing one certificate to secure multiple domains (and their subdomains) while using a single IP. Consider Todd from our previous example has three different domains that he wants to host using the same IP address:

• site1.com
• site2.com
• site3.com

These domains will get listed as a Subject Alternative Name or SAN in a single certificate (unlike SNI where Todd used three certificates one for each domain). Additionally, there is a cap on the number of domains Todd can include in a single certificate (depending on the certificate authority). The hosting company may also include another user named Bob to host example.com by adding it to the SAN.

In case of any changes to the certificate (cancellation or renewal of a certificate, addition or deletion of a SAN), it has to be replaced and set up again for all domains. Larger certificates might take slightly longer (by a few milliseconds) to download and can affect the page load speeds. Domains sharing the same certificate are visible and could create a potential conflict for competitors. For example, Bob and Todd might not be comfortable using the same certificate if they were competing companies. For multi-domain certificates shared between organizations EV (Extended Validation) and OV (Organization Validated) SANs cannot be issued. In this example, since Bob and Todd are working with different organizations, the CA would not issue these certificates to them.

Get a PositiveSSL Multi-Domain DV Certificate for Your Website and Save 88%

On the other hand, with SNI we set up a unique certificate for every domain. It can be used to host millions of domains on the same IP address, using multiple certificates. The certificate size is typically smaller, and it avoids conflict between competing companies since each certificate is restricted to be used by a single domain.

To summarize, we can install SNI or multi-domain SSL certificates based upon specific user requirements, to host a large number of domains or subdomains on a single IP. In case of compatibility issues, or for sites that do not support SNI, we can use multi-domain SSL that uses a single certificate. If comfortable using multiple certificates for multiple domains, we can utilize SNI as an effective solution.

Which SSL Certificate Are Compatible With SNI?

All Comodo SSL certificates are compatible with SNI.