Eric and Igor, you're right - SNI works nice with TLS1.x. In my case it was some weird compatibility issues, not related to SNI. Thank you very much! Vitaly
On Tue, May 24, 2016 at 9:37 AM, linux.il <linux...@gmail.com> wrote: > >> > On Mon, May 23, 2016 at 5:16 PM, Eric Covener <cove...@gmail.com> >> wrote: >> >> >> >> > For some reason if I add "-TLSv1" to SSLProtocol directive in my >> default >> >> > SSL vhost, SNI isn't working anymore: >> >> > >> >> > "SSLProtocol All -SSLv2 -SSLv3 -TLSv1" >> >> > >> >> >> >> What protocol is used? Does the client send the SNI extension? >> >> >> > I'm using the same "curl" and "wget" for testing. As far as I disable >> TLS v1.0, I get "curl: (35) SSL connect error" and >> > "ERROR: certificate common name “mydefault-ssl-vhost-name” doesn’t >> match requested host name “my-vhost-name”" >> > in wget. >> > BTW, similar issue reported here >> http://serverfault.com/questions/700143/does-sni-really-require-tlsv1-insecure >> >> >> You need to use sni capable client. For example use -H to set the Host >> header for curl when trying to connect to non-default vhost. >> > > Sure, agree. > Of course, I can re-read changelogs and run sniffer, but IMHO my clients > do support SNI - I use the same two clients. SNI works well when server > supports TLS 1.0, and doesn't work without TLS1.0. > >
