> Le 28 juil. 2017 à 17:48, Emmanuel Hocdet <m...@gandi.net> a écrit : > >> >> 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
to be exact: /default_cert/have at least one certificate in bind configuration/ Manu
