The objective of introducing virtual host on the HTTP server is to make the multiple domain names reuse one IP address to balance the supply of IPv4 addresses. The server can allocate requests to different domain names (virtual hosts) to process according to the hosts specified in client requests. On an HTTPS server where the IP address is shared by multiple domain names (virtual hosts), when the browser accesses an HTTPS site, an SSL connection is established first with the server. The first step to establish an SSL connection is to request a certificate from the server. The server sends a certificate irrespective of the domain names. This is because the server cannot determine the domain name accessed by the browser.
Server name indication (SNI) is an SSL/TLS extension that is used to resolve the issue of a single server using multiple domain names and certificates. Before the server is connected to establish an SSL connection, the domain name (host name) of the site to be accessed is sent first, so that the server returns an appropriate certificate based on the domain name.
Now, most operating systems and browsers support SNI extension. This function is embedded in OpenSSL 0.9.8 and Nginx of the new version also supports SNI.
When the client does not support SNI, the HTTPS access may become abnormal when you access WAF.
When a browser that does not support SNI is used to access a website that uses WAF, the WAF does not know the domain name requested by the client therefore, it cannot retrieve the corresponding virtual host certificate to exchange with the client. The Web application firewall can only use an embedded default certificate to perform the handshake with the client. In this case, the browser of the client displays a message “Certificate not trusted”.
If the client does not support SNI, the following symptoms may occur:
- On the mobile App client, the iOS client can be normally accessed but the Android client cannot be normally opened.
- The browser displays a message indicating the certificate is untrusted after a Web page is opened.
Capture the SSL handshake packet on the client to determine whether the client supports SNI. Assume that the Chrome browser is used to access the official website of Alibaba Cloud.
Otherwise, the client does not support SNI extension. For clients that do not support SNI,
- We recommend that you upgrade the browser or try using later version of the browsers such as Chrome and Firefox.
- For third-party callbacks from WeChat and Alipay, use the IP address of the origin to bypass the Web application firewall.
- SNI supports the following desktop browsers:
- Chrome 5 and later versions
- Chrome 6 and later versions (Windows XP)
- Firefox 2 and later versions
- IE 7 and later versions (running in Windows Vista/Server 2008 and later versions, IE of any version in Windows XP OS not supporting SNI)
- Konqueror 4.7 and later versions
- Opera 8 and later versions
- Safari 3.0 in Windows Vista/Server 2008 and later versions or Mac OS X 10.5.6 and later versions
- SNI supports the following libraries:
- GNU TLS
- Java 7 and later versions (serving as the client only)
- HTTP client 4.3.2 and later versions
- libcurl 7.18.1 and later versions
- NSS 3.1.1 and later versions
- OpenSSL 0.9.8j and later versions
- OpenSSL 0.9.8f and later versions (flags must be configured)
- QT 4.8 and later versions
- Python3, Python 2.7.9 and later versions
- SNI supports the following mobile browsers:
- Android Browser on 3.0 Honeycomb and later versions
- iOS Safari on iOS 4 and later versions
- Windows Phone 7 and later versions
- SNI supports the following servers:
- Apache 2.2.12 and later versions
- Apache Traffic Server 3.2.0 and later versions
- HAProxy 1.5 and later versions
- IIS 8.0 and later versions
- lighttpd 1.4.24 and later versions
- LiteSpeed 4.1 and later versions
- Nginx 0.5.32 and later versions
- SNI supports the following command lines:
- cURL 7.18.1 and later versions
- wget 1.14 and later versions