Hello Warren,
On Tue, 22 May 2018 at 15:48, Warren Rohner <[email protected]> wrote: > The other day I inadvertently appended a trailing dot to the hostname > for one of our sites (e.g. https://www.example.com.), and when I did > this HAProxy returned the default cert to the browser rather than the > expected cert for that particular site. I'm not certain, but could > this be a possible bug in the HAProxy code that matches servername > provided by browser's TLS SNI extension against all loaded certificates? The browsers are supposed to strip the trailing dots from SNI, as per: https://tools.ietf.org/html/rfc6066#section-3 > The hostname is represented as a byte string using ASCII encoding > without a trailing dot. I know they currently don't, but that doesn't mean there is a bug in haproxy. curl does it correctly: https://github.com/curl/curl/commit/5de8d84098db1bd24e7fffefbe14e81f2a05995a Mozilla has a bug report about this here: https://bugzilla.mozilla.org/show_bug.cgi?id=1008120 There is also a discussion about the disparity between SNI and the http host header on the HTTP WG: https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0430.html However, none of this indicates that a *server* should drop the trailing dot from the incoming SNI and I agree. Looks like browser vendors are not very keen on fixing those edge cases, as can been seen from the bug reports, however I do not agree that we should be dropping the trailing dot in haproxy. If you need a workaround in haproxy, I suggest you configure this alternative SNI->cert mapping using crt-list: https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#5.1-crt-list cheers, lukas
