I'm looking for a simple way to know if a server is using the Server Name Indication SSL extension for its HTTPS certificate on a website. A method that uses either a browser or Unix command line is fine.
SNI is initiated by the client, so you need a client that supports it. Unless you're on windows XP, your browser will do. If your client lets you debug SSL connections properly (sadly, even the gnutls/openssl CLI commands don't), you can see whether the server sends back a server_name field in the extended hello. Note that the absence of this field only means that the server didn't use the server_name in the client hello to help pick a certificate, not that it doesn't support it.
So, in practice the easiest test is to simply try connecting. For this you need to know two names that resolve to the same IP, to which an ssl connection can be made. https is easiest as you can then simply browse to both names and see if you're presented with the correct certificate.
There are three outcomes:
A slightly more complicated test which will yield more info is to have wireshark open and capturing while browsing. You can then find the relevant packets by filtering for ssl.handshake. The screenshots below are an example of a client hello/server hello pair where SNI is supported:
Again, of course the absence of a server_name field in the server hello does not indicate that SNI is not supported. Merely that the client-provided server_name was not used in deciding which certificate to use.
The one liner you are probably looking for to detect the presence of a SSL/TLS Server Name Indication extension header is:
openssl s_client -servername www.SERVERNAME.com -tlsextdebug -connect www.YOURSERVER.com:443 2>/dev/null | grep "server name"
www.SERVERNAME.com is the SNI value you're testing and
www.YOURSERVER.com is the domain name or IP address of the TLS-capable server you're testing.
The command line uses
s_client (see s_client(1)) to connect to the server at
www.YOURSERVER.com on port
-tlsextdebug option turns on TLS extension debugging output. The
-servername option tells the
s_client program to pass
www.SERVERNAME.com as the value of the SNI field in the ClientHello packet during the TLS handshake.
2>/dev/null simply hides stderr output (which can be noisy), and the
| grep "server name" pipeline filters stdout to display the TLS extension called "server name" in
s_client's TLS extension debugging output.
If you see a line of output such as
TLS server extension "server name" (id=0), len=0
then the server is returning SNI header information in its ServerHello response. If you don't, then it's possible the server either does not support SNI or it has not been configured to return SNI information given the name you're asking for. In this case, double-check that you are using a domain name in the
-servername option that the server should respond with SNI information about.
You can use
openssl to fetch and query the certificate.
openssl s_client -connect
grep to find the "DNS:" info
openssl s_client -connect alice.sni.velox.ch:443 | openssl x509 -noout -text | grep DNS:
% openssl s_client -connect alice.sni.velox.ch:443 | openssl x509 -noout -text | grep DNS:
depth=2 C = BM, O = QuoVadis Limited, CN = QuoVadis Root CA 2
depth=1 C = BM, O = QuoVadis Limited, CN = QuoVadis Global SSL ICA G2
depth=0 C = CH, ST = Zuerich, L = Zuerich, O = Kaspar Brand, CN = alice.sni.velox.ch
The last line shows all the SNI entries present in the certficate: