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
