Yes, we sure do. This fairly recent extension of the TLS protocol allows you to indicate which hostname is being contacted by the browser at the beginning of the handshake process. This allows a server to connect multiple SSL Certificates to one IP address and load the correct site or application for the user.

Previously we did not support this, because various web servers did not. But if you use Apache 2.2.12 or higher (with mod_ssl), Microsoft IIS 8 or higher, HAProxy 1.5 or higher or any other enabled server, you can now take advantage of SNI and maximize the use of IP addresses, especially since IPv4 is getting so scarce.

When you attach/bind a SSL certificate to your ALF Pack/config for Load Balancing or the Web Application Firewall, you will see a checkbox to indicate whether it should be attached as SNI or not. Checked = SNI enabled, unchecked means it is attached the standard way which is IP-based.

There is one limitation, however. SNI is not supported with Subject Alternative Name (SAN) extension certificates. So if you want to support SSL for,, you will need 3 SSL certificates. You can NOT have one SSL with SAN enabled to cover and (unless it is a wildcard) and then a 2nd SSL certificate for  The bottom line, if you want to use SNI, each certificate must have one domain configured in it. Yes, it is true that if you order a cert for many SSL providers also add as a SAN at no additional cost, and this is fine because it is ignored. Just make sure that the primary name on the cert is the one you want.

If you have many domains behind one IP, an alternative is to use a single SAN certificate instead of individual SNI certificates for each one. We’ve always supported this. SAN certificates are common in the CDN industry, for example, where dozens (perhaps hundreds) of domains are added to a single SSL certificate. In this situation, you would just bind it as a regular certificate instead of a SNI.