![]() ![]() Where is the SNI value you're testing and is the domain name or IP address of the TLS-capable server you're testing. 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 -tlsextdebug -connect 2>/dev/null | grep "server name" ![]() Merely that the client-provided server_name was not used in deciding which certificate to use. The screenshots below are an example of a client hello/server hello pair where SNI is supported:Īgain, of course the absence of a server_name field in the server hello does not indicate that SNI is not supported. You can then find the relevant packets by filtering for ssl.handshake. You get two different certificates, both for the correct name: SNI is supported and correctly configured.Ī slightly more complicated test which will yield more info is to have wireshark open and capturing while browsing.You get the wrong certificate for at least one of them: either the server does not support SNI or it has been configured wrong.You get a wildcard certificate (or one with a subjectAltName) which covers both names: you learn nothing.https is easiest as you can then simply browse to both names and see if you're presented with the correct certificate. For this you need to know two names that resolve to the same IP, to which an ssl connection can be made. So, in practice the easiest test is to simply try connecting. 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. 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. Unless you're on windows XP, your browser will do. SNI is initiated by the client, so you need a client that supports it.
0 Comments
Leave a Reply. |