> Le 28 juil. 2017 à 16:24, Christopher Faulet <christopher.fau...@capflam.org> > a écrit : > > Le 28/07/2017 à 12:41, Emmanuel Hocdet a écrit : >> A useless certificat should be provide with haproxy configuration?, it’s >> definitely a workaround. It’s legacy from pre SNI. > > Not really. The default certificate is not useless. It is the certificate to > use when no other matches. Expect if you use the "strict-sni" option, it > should be chosen carefully, because everyone can fallback on it. And by > default, "strict-sni" is disabled. >
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. > But here the question is not to know if having a default certificate is a > good or a bad thing but it is if an SSL listener without any certificate is > an error or not. I think it should be by default, because this is the current > behavior and some users may want to rely on it to detect problems. So if we > want to support it, it should be done using a keyword. > 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. > Then, I agree that the feature could be nice, especially, as Willy said, if > we add a way to load certificates on the fly. But I still think that having a > listener rejecting all connections is a bit clumsy. It could be far better to > parse its configuration but disable it. However, I don't see an easy way to > do this automatically :) So, for now, maybe having a keyword to let HAProxy > starts is a good compromise. Manu
