Hi,
> $ openssl s_client -state -quiet -connect xx.xx.xx.xx:443 > > SSL_connect:before/connect initialization > SSL_connect:SSLv2/v3 write client hello A > SSL_connect:SSLv3 read server hello A > depth=4 /C=NL/O=xxx/CN=xxx > verify error:num=19:self signed certificate in certificate chain > verify return:0 > SSL_connect:SSLv3 read server certificate A > SSL_connect:SSLv3 read server key exchange A > SSL_connect:SSLv3 read server done A > SSL_connect:SSLv3 write client key exchange A > SSL_connect:SSLv3 write change cipher spec A > SSL_connect:SSLv3 write finished A > SSL_connect:SSLv3 flush data > SSL_connect:SSLv3 read finished A > GET /admin/ HTTP/1.0 > > SSL_connect:SSL renegotiate ciphers > SSL_connect:SSLv3 write client hello A > SSL_connect:SSLv3 read server hello A > depth=4 /C=NL/O=xxx/CN=xxx > verify error:num=19:self signed certificate in certificate chain > verify return:0 > SSL_connect:SSLv3 read server certificate A > SSL_connect:SSLv3 read server key exchange A > SSL_connect:SSLv3 read server certificate request A > SSL_connect:SSLv3 read server done A > SSL_connect:SSLv3 write client certificate A > SSL_connect:SSLv3 write client key exchange A > SSL_connect:SSLv3 write change cipher spec A > SSL_connect:SSLv3 write finished A > SSL_connect:SSLv3 flush data > SSL3 alert read:fatal:handshake failure Ok, its clear what Apache is doing. After matching the /admin/ path, Apache triggers a SSL renegotiation and within that renegotiation requests the client certificate from the browser. Because this all happens with a renegotiation, this is probably valid behavior from a SSL/TLS perspective. It is still a layering violation imho, because we trigger layer 5 renegotiation by matching a layer 7 event and I would rather avoid that. > In the testing phase (now), some clients have issues with the app > (because they have a certificate in their browser). On Apache/F5 they > are not asked for a certificate in using the app, only admins are. I understand this now; your actual customers are seeing this, if they have at least 1 client certificate in the browser, even though they don't use, care and know about the /admin/ path, which you are only using internally. I see why this sucks. > If it is not possible to do this with haproxy (because it is invalid > according to the spec) then I'll probably suggest they move the admin > interface out of the user-facing part of the app. Yes, I suggest you do this. You will need to do this with a second bind statement, which means either moving it to a different port or to a different IP address. What would make sense in HAproxy however is the possibility to set the verify command based on SNI values and I think there are some very valid use cases that could benefit from it (SNI based virtual hosting with different client-cert settings or like in your case a dedicated admin interface). We already have a snifilter for crt-list [1], extending "verify" with a snifilter is probably doable. Regards, Lukas [1] http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#5.1-crt-list
