Earlier today, Lone Learner asked Why is there no certificate error while visiting google.net although it presents a certificate issued to google.com?

The accepted answer explains that the issue was caused by an SNI Hole.

You've fallen into a "SNI hole". Google will present a different certificate if there is no "Server Name Indication" given in the client's TLS handshake part.

The top search result for "What is an SNI Hole" is the question page for What are the security implications of enabling a SNI-hole on a web server?, which isn't much help for those unfamiliar with the term.

What exactly is an SNI Hole?

  • 1
    I gave a bit more detail in an answer from 2015. Jul 10, 2017 at 21:09
  • 1
    Since there are already several good answers here, I'll just add that I called it a SNI-hole in my original question because I couldn't find any references to that sort of SSL configuration and I needed a concise way to describe it in the question title. SNI/TLS developers may have a different term for it.
    – Parker
    Jul 12, 2017 at 1:42

3 Answers 3


SNI (Server Name Indication) is a TLS (Transport Layer Security) extension in which the client presents the server the domain name for the target it wants to access within the TLS handshake. It is used in cases where there are multiple virtual servers with different certificates on the same IP address, so that the server can present the correct certificate.

Insofar it is similar to the HTTP host header in the HTTP request, which is used to select the matching virtual host configuration - only the Host header cannot be used to select the certificate since it is sent inside the HTTP request. (i.e. after the TLS handshake is already done).

Since the SNI TLS extension is optional, some clients may not send this extension. This is the case with openssl s_client without the -servername argument, but also with many TLS libraries in different programming languages. And while all modern browsers use SNI, older browsers like IE8 on XP do not use it.

If such a client connects to a server which has multiple certificates, the server does not know which certificate the client actually needs, i.e. the client falls into the "SNI hole" by not using the SNI extension. In this case the server usually either sends an error back (or sometimes just closes the connection) or uses a default certificate explicitly or implicitly configured for this purpose.

  • Not just error messages - its possible to host entire services this way. At the time I wrote the question, there were several new vulnerabilities out that created a mutually-exclusive set of supportable clients (in order for Chrome to connect to our site, we would have needed to disable support for older clients). With a SNI hole, I could maintain a legacy HTTPS API for old web clients (Java 5/6, IE6-8) without compromising newer clients. Old clients fall through to the default host (deprecated cipher suites), while newer clients connect to the Server Indicated by Name (modern cipher suites).
    – Parker
    Jul 12, 2017 at 1:52
  • @vallismortis: It's not clear for me what you are referring to with "Not just error messages". I showed three ways the server will typically react: sending error back (in the TLS handshake, i.e. TLS alert), simply closing the connection or using a default certificate. And the last option of using a default certificate of course makes it possible to continue with the TLS handshake and thus offer any service after the handshake is done as long as the client accepts the certificate. Jul 12, 2017 at 5:34
  • @Steffen-Ulrich This isn't about a "default certificate" - the cipher suites and SSL protocols may also be configured differently on the default host while using the same SSL certificate. Even the same certificate can be set up differently, with different sized DH keys, or chains to different certificate roots. Yes, you could offer a different certificate entirely, but in my experience that has been unnecessary.
    – Parker
    Jul 12, 2017 at 12:05
  • @vallismortis: I don't see how this comment is related to the question. The suites and protocols can in theory be different for each certificate the server offers because the decision which certificate and which cipher and protocol gets used is done after receiving the initial ClientHello. This has nothing to do specifically with SNI hole. Jul 12, 2017 at 12:43
  • @Steffen-Ulrich You presented a very narrowly defined use case for a SNI hole that is based on serving different certificates to clients. There is a broader utility in using the same certificate to support deprecated protocols and cipher suites for older clients.
    – Parker
    Jul 12, 2017 at 13:01

An SNI hole is when you have a default site set up for an IP address that does not require SNI to be present in order to complete an HTTPS connection.

This is, in fact, how all HTTPS connections used to work, before SNI existed. Each HTTPS site required a routable IP address, not just a hostname. So, when set up this way, any port 443 request to that IP address will resolve to that one site, even if you have many HTTP (port 80) sites using virtual hostnames. This was a perennial problem for people who reused webservers for a number of sites, and then decided to set up SSL/HTTPS for one. If you're running http://example.com and http://contoso.com on the same server, and then set up HTTPS for example.com, results for http://contoso.com will still work correctly, but requests for https://contoso.com will return results from https://example.com, albeit with a certificate error.

What's you're seeing here is effectively the same thing. If you don't send the SNI extension telling Google's servers what hostname you're trying to connect to, the default for the Google webserver IP addresses is the google.com site, so regardless of which hostname you're trying to connect to, it will be google.com that will respond.

  • And I thought the one-IP/port-per-certificate was just a Microsoft thing that they finally fixed with IIS 8... You're saying that HTTPS was built that way? Jul 11, 2017 at 20:31
  • 3
    @Michael Yes, that was an OS-independent problem. Apache-on-unix administrators had to have an IP address per certificate too. Go back a little further, before HTTP 1.1 made the Host header mandatory, and you had to have an IP address per hostname even without SSL.
    – user54862
    Jul 12, 2017 at 1:24

You contacted a SNI server that actually has more than one SSL domain with a non-SNI client. The server guessed wrong.

Same basic story when contacting a HTTP/1.1 server with a HTTP/1.0 client. The server guesses.

  • 2
    It's not exactly a guess...It's the site with the default binding for the IP.
    – Xander
    Jul 10, 2017 at 21:20
  • 1
    It's the server admin who guesses :-) Jul 12, 2017 at 20:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .