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)
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
Currently the clean solution seems, for me, to use dedicated ip:443 bind.
It is not a scalable and flexible solution However.
Roberto
