On 04/21/2017 07:27 AM, Willy Tarreau wrote:
> On Thu, Apr 20, 2017 at 11:33:17PM +0200, Lukas Tribus wrote:
>> Hello,
>>
>>
>> Am 20.04.2017 um 15:05 schrieb Sander Hoentjen:
>>> A new patch, that puts the order like this:
>>> config:
>>> crt A crt B
>>>
>>> [...]
>>> If A contains wildcard, and B contains exact match, then wildcard is used.
>>>
>>> This last one is different behavior from what is implemented now.
>> People rely on the specific current behavior you are changing already.
>> We made it clear that exact matches always take precedence; inverting the
>> behavior fixes your single use-case but breaks many others.
>>
>>
>> My opinion about your use-case is that your provisioning layer has to handle
>> this and remove, if necessary, any more specific and unwanted lets-encrypt
>> certificates.
>> Maybe the crt-list [1] feature can be an alternative, otherwise, what you'd
>> need from haproxy would be a multi-layered approach, with certificate
>> "weights", which I don't believe makes sense to implement (but should be
>> abstracted into provisioning tools).
> +1
Well, in essence certificate "weights" is what I implemented in the
patch, with the config order determining the weight. While unfortunate
for me, I can understand your reasoning. I do still think my approach
offers more flexibility. Anyway, I attached a new patch which I hope you
will consider :)
As for my own use case, I'll just carry the previous patch myself.
In my case I can't just simply remove a (multi-domain) certificate,
since they may contain names that are not covered by the wildcard. This
means I need to use a neg filter, but I can't use a directory in
crt-list, so I need to specify all certificates in the list. While not a
very large issue it adds unneeded complexity, with a chance for things
to go out of sync.
In the end I would like to say that while I hoped my patch would be
accepted, I appreciate the responses on this mailing list. I prefer
being told no to being ignored. Thanks for this awesome project with a
healthy community. Maybe in the future I can contribute something else :)
Regards,
Sander
commit 2132209181c7fe961396673465bbf619b91a5e02
Author: Sander Hoentjen <shoent...@antagonist.nl>
Date: Fri Apr 21 10:38:06 2017 +0200
Make load order of (wildcard) certificates clearer in docs
diff --git a/doc/configuration.txt b/doc/configuration.txt
index e6ea2cf..fed73b3 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -10226,11 +10226,13 @@ crt <cert>
that directory will be loaded in alphabetic order unless their name ends with
'.issuer', '.ocsp' or '.sctl' (reserved extensions). This directive may be
specified multiple times in order to load certificates from multiple files or
- directories. The certificates will be presented to clients who provide a
- valid TLS Server Name Indication field matching one of their CN or alt
- subjects. Wildcards are supported, where a wildcard character '*' is used
- instead of the first hostname component (eg: *.example.org matches
- www.example.org but not www.sub.example.org).
+ directories. When specified multiple times, the certificates will be looked up
+ in the order they are specified in the configuration, with the exception of
+ wildcard certificates, they will always be looked up last. The certificates
+ will be presented to clients who provide a valid TLS Server Name Indication
+ field matching one of their CN or alt subjects. Wildcards are supported, where
+ a wildcard character '*' is used instead of the first hostname component (eg:
+ *.example.org matches www.example.org but not www.sub.example.org).
If no SNI is provided by the client or if the SSL library does not support
TLS extensions, or if the client provides an SNI hostname which does not
