Hello Julian, On Thu, 22 Nov 2018 at 20:09, Julian Wiesener <[email protected]> wrote: > > Hi Lukas, > > On Thu, 22 Nov 2018 19:39:11 +0100 > Lukas Tribus <[email protected]> wrote: > > Trying to understand the use-case better here, binding to any IP is > > not acceptable? Your client *needs* to bind to specific IPs? > > one bind for multiple IPs would reduce the flexibility of the config, you > could not longer set different Backends on different IPs that share one > certificate (directory) for example. There are clealy ways to reduce > the reload times by changing the configuration, however there is a > strong preference to keep the current configuration layout and solve > the problem in code, if there are no strong reasons against it.
You are advocating for a new code path and along with an additional configuration knob. Feature bloat is a problem and if a use-case can be covered by modifying the configuration slightly, I'd personally opt for the latter. We should certainly look at all possibilities to cover the use-case. But I want to make it clear: I'm not the the SSL maintainer or the author, this is merely my personal opinion about this as a contributor. As for flexibility with my 2 proposals you can access the destination IP in an ACL with the dst variable, which I believes gives you everything you need, including backend selection based on the connected IP, all with a single bind statement. I understand that was just an example, but with the ACL variables you should be able to do *a lot*. It sounds like the reason for this is not that you need the same certificate on multiple IP's, but that all certificates are in one directory - which quite frankly would be better addressed in the provisioning layer. The crt-list feature can also be used to selectively load certificates at scale, but it does require the provisioning layer to know which certificates belongs to which bind statement. Just my two cents ... Best regards, Lukas
