On 18.04.2014 11:11, Yann Ylavic wrote: > Agreed, still it may be useful (for some potential client) to get the > real error when it handshakes with an SNI which is not acceptable on > this server, and for the server the sooner the better IMHO.
mod_ssl will send a "Certificate" TLS message either way (whether we return SSL_TLSEXT_ERR_ALERT_WARNING or SSL_TLSEXT_ERR_NOACK). From a client perspective, if you really want to avoid processing/validating the cert (and abort early based on the server's hint that he found no matching certificate), then you can check the ServerHello for the presence of an (empty) SNI extension. With r1585090 / r1588424, we're omitting the warning-level alert, but there's no change for the ServerHello. > Well, if one want to be really strict about SNI, and don't have a > wildcard cert (say the poor man, still with multiple name-based > vhost), is the default SSL vhost relevant? Yes, as it simply the "one and only" SSL host for a given TCP port, in this case, and completely denying access to non-SNI clients that early in the handshake already isn't a very useful thing to go for, I think. > to deny at handshake time, with the relevant message for the client to > know why (instead of 400, 503 or even bad cert which just leaks > another service). Browsers are pretty bad with handling failures at the TLS level (fatal alerts in particular). Handling them with a decent ErrorDocument etc. on the HTTP layer is much better, IMO. Kaspar
