William Lallemand
William Lallemand
What I could do is change a little bit the behavior, we could force the "crt" file to have a ".crt" extension as a requirement for this feature. It's less...
The above commit should fix this, I also added a reg-test which test this with "set ssl cert".
Unfortunately I won't backport this to 2.2, the CLI still has the bundle code and I don't want to risk to break it, so I'm still reverting this in 2.2.
> The current workflow is also inconsistent with the highly opinionated K8s workflow. kubectl will by default create two keys called "tls.crt" and "tls.key" for a TLS secret.. Not "tls.crt.key",...
I don't think think adding a new `crtkey-list` keyword is a good idea, each line generates only one SSL context, you can't have multiple key and crt on the same...
That would be the best option if the options order was preserved from the start, but it does not make sense to preserve order only for one keyword, it would...
Unfortunately this would break a lot of configuration so that is not possible, we will probably proceed this way: - add the "key", "ocsp" etc keywords to crt-list (since it's...
> ```shell > example.com.pem [key example.com.pem.key ocsp example.com.pem.ocsp] > ``` It could work like this indeed, but nothing was pushed in the master repository yet, we'll probably try to have...
Unfortunately the changes are too deep in the configuration parser, and will require to change a lot of things, it's a bit too late to be integrated into 2.6.
No progress on this, should still be tested.