On Fri, Jul 28, 2017 at 11:08:33AM +0200, Christopher Faulet wrote: > But it is definitely in conflict with you current patch. Because without > initial_ctx, we need to have a default_ctx. So I can probably work around > this problem. But before doing it, I prefer to know if your patch will be > accepted or not :)
I think we don't know :-) The only thing I understood is that Manu's patch was a fix but that it didn't find the rest of the breakage you spotted, and conflicts with another possible fix. So you seem to be the only two ones understanding what is broken and why (or each having an idea about part of it), so I think we'll calmly rely on you both to figure what needs to be fixed. > From my point of view, I can't see why anyone would want to start a SSL > frontend without any certificate. Because it will reject all connections. > Simos explained his use-case with Letsencrypt. But it is only useful for the > first generation of the first certificate. It is easy to comment the SSL > frontend at this step. Get a certificate from Letsencrypt or generate a > default one by hand is quick and trivial. To automate this part, you can > have a default certificate, probably self-signed, and the strict-sni > parameter on the bind line (You already proposed this solution). For me, > this is not a workaround, this is the way to do it. But that's just my > opinion, I can understand the need :) So I'll let Willy and/or Emeric make > the final decision. I personally think that with the current architecture it does indeed not make much sense to start without any cert, but that in the future we may go towards this direction to further improve what can dynamically be updated without restarting. At the moment Letsencrypt requires manual changes anyway so the reload is inevitable and the extra complexity involved by the changes do not provide any benefit. For the long term we could imagine having native support for Letsencrypt (or whatever else will have replaced it) and think about how to implement it correctly. We might not be that far from being able to do it considering that you're already capable of issuing certs on the fly, which means that some parts already support dynamic certs being loaded. So it means to me that we need to be forwardthinking but that's not a reason for needlessly bloating everything. Baby steps are more reasonable. Just my two cents, Willy
