On Tue, 8 Sep 2020 at 12:39, Teo Klestrup Röijezon <teo.roije...@interops.se> wrote: > > Hey Willy, sorry about the delay.. managed to get sick right after that stuff. > > > I don't understand what you mean here in that it does not make sense to > > you. Actually it's not even about overriding verifyhost, it's more that > > we match that the requested host (if any) is indeed supported by the > > presented certificate. The purpose is to make sure that the connection > > is not served by a server presenting a valid cert which doesn't match > > the authority we're asking for. And if we don't send any servername, > > then we can still enforce the check against a hard-coded servername > > presented in verifyhost. > > To my mind, `verifyhost` is more or less an acknowledgement that "no, this > isn't quite set up perfectly, but we can at least verify with some caveats".
It's about proper certificate validation. > Otherwise, the host could just be taken from the address in the `connect` > keyword before SNI? No, because the address often is an actual IP address, not a hostname, and if it is a hostname, then it often does not match the actual certificate SAN. In a common setup we'd be serving a HTTPS site like www.example.org, so that is the certificate. However the backend servers that haproxy accesses is not www.example.org - because www.example.org would actually point to haproxy, not a backend server. Backend servers could be www1.example.org and www2.example.org, so there is a mismatch. So in the most common configuration, those hostnames do not match, which is why we need to specify it, with the intention to fully validate it. Lukas
