IP SSL vs SNI SSL

What is the difference between IP SSL vs SNI SSL certificates? Here’s how to choose the right one for your website

When it comes to choosing the right SSL/TLS certificate, everyone gets confused. It’s pretty obvious because there are so many types of certificates, versions, compatibility, verification levels, and technical components that selecting the most suitable certificate becomes a daunting process. One of the common issues people face is understanding the difference between IP based SSL and SNI SSL certificates. In this article, we address all the relevant points on the topic IP SSL vs SNI SSL certificate so you can make an informed decision.

IP Based SSL vs SNI SSL Certificate: Key Differences

Technical Features

A Server name indication (SNI) certificate, also known as SNI cert, is an extension of the secure TLS protocol. SNI enables most modern web browsers (clients) to indicate which hostname (domain name) they’re trying to connect to during the TLS handshake process. Such host headers enable servers to understand which website’s certificate chain it is supposed to fetch to establish an HTTPS connection. Because of SNI, all of the sites hosted on the same IP address and same port can have separate SSL certificates.
Note: We have included SNI technology in an easy-to-understand way with a fun example in the latter part of this article.
Now, let’s compare this to an internet protocol (IP) SSL certificate, which is installed on a domain that’s hosted on a dedicated IP address. It attaches a website with its unique IP address. So, there would be one SSL certificate for one website on one dedicated IP address.

User Classification

Cloud-based services providers use SNI SSL certificates. These services include website builders, content distribution networks (CDNs), eCommerce platforms, or any other anything-as-a-service (XaaS) provider that is supplying a common platform for many websites.

IP SSL certificates are used by anyone who has hosted a website on a dedicated server with unique IP address.

Compatibility

SNI compatibility (earliest versions)
• IE 7 +,
• Mozilla Firefox 2.0 +,
• Opera 8.0 +,
• Chrome 5.0.342.1 +,
• Safari 3.0 +,
• Mobile Safari for iOS 4. and later, and
• Windows 7+ for Phone.

Note: Internet Explorer (any version) on Windows XP does not support SNI.
You must contact your hosting provider to confirm whether they support SNI. If they don’t, you need to host your website on a dedicated IP in order to install an SSL certificate. Your hosting provider would ask you to buy a dedicated IP to secure your website with an SSL certificate if they don’t support SNI.

IP SSL certificates are compatible with all the major browsers and operating systems.

Price

SNI SSL certificates’ prices are available only upon request. CAs generally customize each certificate based on the requesting organization’s requirements.
Price for IP SSL
All the SSL certificates available on cheapSSLsecurity can be used to secure a website hosted on a dedicated IP address. The following SSL certificates will also work if you are looking forward to securing a public facing IP address.

Let’s compare the prices of popular organization validated (OV) IP SSL Certificates

How SNI Certificate is Like a Pink Dress!

Let’s consider a fun example before moving to SNI technology.
Your friend Alice asked you to buy her a pink dress from Bob’s store. When you went to Bob’s shop and asked for the pink dress, he understood which dress you were looking for, because there was only one pink dress in his store. You made the purchase. Transaction completed.
Now, check out the other scenario. What if Bob’s store has 50 pink dresses? Now, it’s a problem because Bob doesn’t know which pink dress Alice is looking for. The purchase won’t be completed until Bob brings the right pink dress.
Because the shop has multiple pink dresses, the “pink dress” description won’t be enough. You ask Alice for more details, and Alice gives you the barcode of the pink dress she is looking for. You give it to Bob, and he knows which exact dress to bring. Easy!

Now, let’s consider the same scenario with TLS’s context.

When a user tries to open a website on a browser, the browser goes to the server (on which the website is hosted) and asks for the site’s digital certificate. This request is made in the HTTP host header. When the server fetches the requested certificate, the browser matches the name on the certificate with the website the user is trying to visit. If the name matches, the TLS connection is established. If not, the users will get a “common-name-mismatch” error page.

Previously, host headers used to specify the IP address of the website it is trying to connect. With this approach, each site had to have its own IP address for the server to understand which certificate it needed to fetch. (In our example, one pink dress per shop.)

In the early days of the commercial internet, only big organizations could afford to have a website and were eligible to pass through the organization validation (OV) process. So, the number of websites was limited, and each website was usually hosted on a unique IP address as a result.

The Problem with Using only IP Addresses in Host Headers

With the rise of the internet, millions of new websites flooded the internet. However, the IP addresses in IPv4 has approximately a total of four billion unique IP addresses, which will eventually get depleted. To slow down the exhaustion of unique IP addresses, the shared hosting environment came into the picture, enabling companies to host multiple websites on the same virtual server using the same IP address. But such sites were not eligible to form a secure HTTPS connection because the server didn’t know which particular website’s certificate it needs to bring as the same IP address was shared by multiple domain names.

To resolve this situation, SNI was introduced in 2003. Since that time, browsers can specify the hostname (website’s name) in the host header instead of the IP address. Now, the server knows which domain name’s certificate it needs to present to the browser during the TLS handshake. In other words, the servers recognize a website by its domain name instead of its IP address during the SSL handshake. This enables all the sites hosted under the same IP address to have separate SSL certificates.

In our example, Bob can recognize a dress by its barcode — which is separate for each dress — instead of the vague description of a “pink dress,” which can be applicable to many apparels available with him.