SNI and how it applies

Transport Layer Security Server Name Indication (TLS SNI) allows clients to include the name of the host they are trying to contact (the "server name") in a request, which allows the server to select and respond with the proper certificate.

The problem: No support for virtual hosting

When TLS 1.0 was first developed, it lacked support for virtual hosting—when a "ClientHello" message is sent to a server, the client expects to receive a "ServerHello" in return with a security certificate identifying the server by name. If the name in the certificate doesn't match the name the client expects, a client should fail the connection and return an error.

With virtual hosting, a single server handles tens, thousands, or millions of independent websites. The server needs to know which certificate it should return. Without a host name in the ClientHello, a server looking to serve HTTPS has no option but to use distinct IP addresses for each certificate. As a CDN, Akamai deploys in hundreds or thousands of locations, requiring hundreds or thousands of Virtual IP (VIP) addresses per certificate. With the exhaustion of freely available IPv4 addresses, this quickly becomes a fundamental scaling problem.

The solution: TLS SNI

The SNI extension routes information that enables virtual hosting—the server name can be included in the ClientHello message, and the proper certificate is included in the ServerHello.

On average, we see roughly 98% of HTTPS requests originate from clients that send TLS SNI. Since a large portion of non-SNI clients are custom applications used by individual customers, the median customer certificate configuration ("slot") sees around 99% of HTTPS requests from clients sending TLS SNI.

  • The end user to Edge server connection: All Standard TLS and some Enhanced TLS certificates are “SNI-only.” This means that the client must use SNI to receive the correct certificate. (For example, the end user's browser application must support SNI.) The remaining Enhanced TLS certificates use “Virtual IP” (VIP) addresses so that even the small number of clients who don’t use SNI still receive the correct certificate. Those clients also work when using the Akamai Shared Certificate, because it doesn't depend on the client using SNI.
  • The Edge server to origin connection: You can choose whether to send an SNI value to the origin. If you choose to do so, it sends the same value as the Forward Host header that is sent to the origin. Then, you can configure your origin to return different certificates based on the SNI value. Additional details on this setup and the caveats that affect it are discussed in Did you enable 'Use SNI TLS Extension'?.