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
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