> Le 28 juil. 2017 à 17:13, Willy Tarreau <w...@1wt.eu> a écrit : > > On Fri, Jul 28, 2017 at 05:04:16PM +0200, Emmanuel Hocdet wrote: >> I talk with the case we don't want a default cert. With strict-sni the « fake >> » default_cert can be use if it as sni (i don't want that ideally). >> with strict-sni: no certificate match sni -> no ssl connection. >> I add strict-sni to haproxy because customers call when browser show warning >> with https on their vhost (without certificat), and they don't wont that. > > That's a good point to keep in mind. > >> The question is: force to have a default certificat is really necessary? >> generate an error or move to a warning? I understand the old use case but >> what about the strict-sni use case? is not incompatible with the default_ctx >> relax. > > The default cert is useful every time the strict-sni is not in use. In fact > you are in the position of a hosting provider with no reason for presenting > your company's name instead of a hosted customer's cert when unknown, but > the other situation is very common : company "acme" has a certificate for > "www.acme.com" and occasionally needs a temporary vhost on "dev.acme.com" > or "cms.acme.com" or "support.acme.com" but they don't want to have to buy > and deploy an extra cert just for this, especially when they already have > a few domains in the alt names of the first cert. So it's very common to > see them just create the new name and fall back to the default cert. For > partners it's not a problem, they see a browser warning, they check it, > can confirm the cert is not for the correct hostname but valid for the same > domain (eg: www.acme.com when they asked for support.acme.com) and they can > pass through. It also happens with multi-tld names. You can have "acme.fr" > redirect to "acme.com" without having to buy a cert for "acme.fr". Just a > warning once in a while and that's all. > > Then of course there's the case of the certificate generation on the fly > which needs one private key. Using that of the default cert is the current > choice and it makes quite some sense. It's obviously exclusive with strict-sni > by definition! > > All these use cases are pretty valid and we just need to keep them all in > mind when seeking the proper fix.
I propose: strict_sni is set and generated_cert is not set: default_cert is optional (with or without warning?) else default_cert is required ++ Manu
