>>> 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. I said I'm using dedicated ip:443 bind as a clean solution because "the current haproxy client certificate management implementation is not optimal nor flexible nor scalable in other configurations" so, in this test we can waste one pubblic IP and an manage an useless additional frontend, having to manage 2 frontend instead of one. One need to use another IP also for only one directory in the some domain if needed... Not so good ! It is simple: if all web server (Apache, IIS, nginx, ...) have such feature, is because it is useful and used ! :D What about if one have many applications each with different client certificate configuration for each directories ? You can leave haproxy implementation as is if you think this is the right way. I found this implementation not at all flexible and far away from haproxy standard mindset. Instead Renegotiation will bring in haproxy for client certificate a more standard way (acl, etc.). I think this is an important feature, but the choice is your ! ... these are "just my two cents" :D 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
