Hi,
On Tue, May 09, 2017 at 07:04:01PM +0200, Daniel Schneller wrote:
> Hi!
>
> > On 9. May. 2017, at 00:30, Lukas Tribus <lu...@gmx.net> wrote:
> >
> > [...]
> > I'm opposed to heavy feature-bloating for provisioning use-cases, that
> > can quite easily fixed where the fix belongs - the provisioning layer.
>
> You are right, that this can be handled outside / in the provisioning layer.
> And I have no problem implementing it there, if it is considered too narrow a
> niche feature. However, I was curious to see, if this is something that other
> people also need constantly -- sometimes you believe you are in a specific
> bubble, but aren't. But from the amount of feedback the original post
> generated, I think I know my anser already ;-)
In fact I'm less opposed than Lukas here given that I have no idea of the
possible impacts nor complexity (but I don't want to have the complete MS
Office suite merged in, just Word, Excel and PowerPoint :-)).
I'd tend to say that since we're progressively evolving in a more dynamic
world where users want the ability to perform *some* updates without
reloading, the day we realize that 90% of the haproxy reloads are only
caused by cert updates, we need to think about a way to address this. I
remember that Thierry started to look at how to feed a cert from the CLI
but apparently it was everything but obvious.
Loading multiple certs could be nice in theory, but there are a few
shortcomings to keep in mind :
- for embedded users you don't want haproxy's date check to become
strict because it's frequent that such devices have a totally
wrong date. Or at least you want to ensure that you always keep
the most recent cert and never kill any outdated one.
- renewed certs can and will sometimes provide extra alt names, so
they are not always 100% equivalent.
- renewed certs will also change the key size once in a while, and
sometimes the algorithm. Technically speaking it might cause
difficulties to change this on the fly, or at least some
verifications have to be performed at load time.
- I think that most of the crt-list config is per-certificate file
and not per-name. That might also make certain things more
complicated to configure
That said, given that we can already look up a cert based on a name,
maybe in fact we could load all of them and just try to find a more
recent one if the first one reported by the SNI is outdated. I don't
know if that solves everything there.
In any case, this will not provide any benefit regarding let's encrypt
or such solutions, because the next cert would have to be known in
advance and loaded already, so reloads will have to be performed to
take it into account. So I think that the approach making it possible
to feed them over the CLI would still be mor interesting (and possibly
complementary).
It could be interesting to study what it would require to implement
a "strict-date" option or something like this per certificate to
enable checking of their validity during the pick-up. Still, one
point has to be kept in mind. Daniel I'm pretty sure that most users
would prefer the approach consisting in picking the most recent
valid cert instead of the last one as you'd like. I don't really
know if it's common to issue a cert with a "not-before" date in the
future. And that might be the whole point in the end.
Hoping this helps,
Willy
