Sorry for being late with my reply. On 16.04.2014 16:00, Yann Ylavic wrote: > Before this commit, the client knew it was not reaching any vhost by > receiving an SSL alert (warning), and could stop.
In practice, most SNI-capable clients have ignored these warning-level alerts (which is completely in line with RFC 5246, which states "If an alert with a level of warning is sent and received, generally the connection can continue normally"). Whether or not the server acknowledges to have a suitable cert for the name requested by the client in the SNI extension isn't that relevant, IMO. The most important (and absolutely essential) thing the client has to do is to check the expected name against those included in the certificate (RFC 6125, acceptable reference identifiers vs. presented identifiers), irrespective of any potential TLS warning-level alert he might have received on the connection. > The new option would prevent the default vhost to be used (when SNI is > available), and let the client know (still). As pointed out by Rüdiger in his latest message, there is no point in disallowing access to the default vhost based on whether an SNI extension was sent by the client or not: the default vhost is effectively the "global" one for SSL connections - "SSLEngine on" should only be configured within vhosts, see also [1]. Ever since mod_ssl was added to 2.0.x [2], a "_default_:443" vhost was used to handle all SSL requests. Thanks for your vote with r1588257, Yann, in any case - now merged to 2.4.x with r1588424. Kaspar [1] https://mail-archives.apache.org/mod_mbox/httpd-dev/201011.mbox/%3c7bf538e6-dafb-4638-b845-09bedf673...@rcbowen.com%3E [2] https://svn.apache.org/viewvc?view=revision&revision=91707
