Lukas Tribus schreef op 09/01/14 00:08:
Thank you again for the great explanation both. It is indeed just the user facing part, functional wise the client certificate just works. I think I like the setup with two apps better than what we have now, should also make it easier to firewall the admin part better.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 failureOk, 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
Cheers,
smime.p7s
Description: S/MIME-cryptografische ondertekening
