>>> For those first 3 points we don't need renegotiation.
>>> Current implementation is buggy, but once we merge:
>>> "BUG/MEDIUM: ssl: fix verify/ca-file per certificate"
>>> all those issues will be addressed, without complex workarounds or
>>> multiple IPs.
For 2.Allow to have the default cert to use for non-SNI client for the
same domain used also for client certificate request
I done a test that demonstrates a not working behavior.
Emmanuel write me why. See test case and Emmanuel answer:
My test Case and question:
. haproxy.conf:
bind <IP1>:443 ssl crt-list /etc/haproxy/crt-list.txt
. crtlist.cfg:
<path>/cert1.pem [ca-file /<path>/ca1.pem ca-file
/<path>/ca1.pem verify optional]
<path>/cert2.pem
<path>/cert3.pem
but any request for any domain for any hostname pop-up
on the client side client certificate selection window
popup selection is presented to client also for domain
not in cert1.pem but in cert2.pem and cert3.pem.
Also: what is the default certificate for not-SNI
client if one use crt-list file instead of crt on bind line ? (without crt-list
file is the first crt in the bind line)
Emmanuel answer:
The default cert is always the first cert parsed. It's
cert1.pem in your configuration.
The default cert is a source of errors because it's
used in the SSL negotiation.
The [ca-file <pem> verify optional] is also present in
the SSL negotiation, the switch to the correct cert will not override it.
=> You must move the cert1.pem later in your
configuration and let the default cert as neutral as possible.
It's a open problem with openssl. I have trying to
create a neutral SSL context (without any certificat) before select the
certificat, but openssl don't like that.
Without a real solution, this behaviour should be
documented.
I think using renegotiation you'll manage all client cert aspects and improve
overall client cert haproxy management process.
Roberto
-----Original Message-----
From: Lukas Tribus [mailto:[email protected]]
Sent: sabato 4 marzo 2017 12.15
To: mlist <[email protected]>; '[email protected]' <[email protected]>
Cc: 'Emmanuel Hocdet' <[email protected]>
Subject: Re: Client Cert Improvements
Hi Roberto,
Am 04.03.2017 um 11:51 schrieb mlist:
>
> Hi,
>
> after discussing about haproxy client certificate management with
> other forum users/devel, I ask if it is possible to improve haproxy
> client certificates management
>
> with this case specs:
>
> Allow haproxy to manage client certificates using technique like SSL
> Renegotiation - as Apache do (see below). This will introduce many
>
> improvements allowing to apply simply up to the level of directory and
> allowing to use acl logic haproxy just employ, to the client certificate
>
> management process.
>
> Apache (SSLVerifyClient Directive)
>
> This directive sets the Certificate
> verification level for the Client Authentication. Notice that this
> directive can be used both in per-server and per-directory context. In
> per-server context it applies to the client authentication
>
> process used in the standard SSL handshake when a connection is
> established. In per-directory context it forces a SSL renegotiation
> with the reconfigured client verification level after the HTTP request
> was read but
>
> before the HTTP response is sent.
>
> Also "IIS" allow this level of configuration
>
> Requisites:
>
> 1.Share one IP, without forcing to use different bind on different
> ip:443 pairs wasting IPs
>
> 2.Allow to have the default cert to use for non-SNI client for the
> same domain used also for client certificate request
>
> 3.Avoid trick configuration with localhost:port redirection that
> introduce confusion and pose issues on complex configurations (ie:
> http://serverfault.com/questions/662662/haproxy-with-sni-and-different-ssl-settings)
>
For those first 3 points we don't need renegotiation.
Current implementation is buggy, but once we merge:
"BUG/MEDIUM: ssl: fix verify/ca-file per certificate"
all those issues will be addressed, without complex workarounds or
multiple IPs.
> 4.Allow to filter with simple acl at which: domain, hostname,
> directory or sub directory level haproxy start client certificate
> request so on the client side will be popped up client cert selection
> window
>
It doesn't sound like you actually need this feature (you said "using a
dedicated ip:443 is a clean solution", which does not cover requisite 4).
I would rather not have a complex feature that basically nobody ever
uses, that introduces a lot of complexity in our code and that probably
triggers a ton of client side bugs in browser and MITM SSL interception
devices.
We need SNI based client certificate configuration. It is buggy right
now and will be fixed.
just my two cents,
lukas
