Bug #4324


HAproxy and SSL client certificate validation

Added by Stéphane Lapie almost 7 years ago. Updated almost 7 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
1.00 h
Plus Target Version:
Affected Version:
Affected Plus Version:
Affected Architecture:


I just stumbled upon something with HAproxy that is probably not the expected/intended behavior when building an ACL :
  • "SSL client certificate valid." → Even though it generates a static string "ssl_fc_has_crt ssl_c_verify 0", it still requires a value
    • Minor annoyance, that should probably be changed.
  • "SSL client certificate valid." → When using the generated condition "ssl_fc_has_crt ssl_c_verify 0", I noticed a huge problem with most browsers :
    • Browsers don't send the client certificate all the time, which leads this condition to fail.
    • This does not take in account the cached client certificate in the session.

Following the documentation :

ssl_c_used : boolean
  Returns true if current SSL session uses a client certificate even if current
  connection uses SSL session resumption. See also "ssl_fc_has_crt".

ssl_fc_has_crt : boolean
  Returns true if a client certificate is present in an incoming connection over
  SSL/TLS transport layer. Useful if 'verify' statement is set to 'optional'.
  Note: on SSL session resumption with Session ID or TLS ticket, client
  certificate is not present in the current connection but may be retrieved
  from the cache or the ticket. So prefer "ssl_c_used" if you want to check if
  current SSL session uses a client certificate.

I worked around the problem on my side by creating a custom ACL that checks not only the front connection, but the whole session :

ssl_c_used ssl_c_verify 0

For the (hopefully) few people who still have a need for SSLv3 (i.e no TLS tickets) in this day, this should cover every case :

ssl_c_used ssl_c_verify 0 or ssl_fc_has_crt ssl_c_verify 0

Actions #1

Updated by Pi Ba almost 7 years ago

Thanks for reporting this, my suspicion is that 'ssl_c_used ssl_c_verify 0' would be enough for all cases.

Have you confirmed that the second combination 'ssl_c_used ssl_c_verify 0 or ssl_fc_has_crt ssl_c_verify 0' is actually required in some cases? That would complicate the 'Client certificate verify error result' acl..

Actions #2

Updated by Stéphane Lapie almost 7 years ago

No, I haven't. In my production settings, I am only using "ssl_c_used" since I can guarantee for sure we are in a TLS environment.

I just wrote the or expression "to make 100% sure nothing is forgotten", but I honestly think this is overkill.
My personal understanding is that "ssl_c_used" encompasses also any case also handled by "ssl_fc_has_crt", but I didn't probe the source code to confirm whether this is the case or not (because then, this would then put in question why "ssl_fc_has_crt" still exists... unless it's only 100% for compatibility reasons)

Actions #3

Updated by Stéphane Lapie almost 7 years ago

Just reporting another little very minor thing, I am testing the latest version for which you added ACL negation and a lot of stuff I talked to you about on IRC the other day, I fumbled a bit before figuring out you now have to actually register a "None" entry on top of the desired client certificate CA. :) Also, any other CA that was declared before will now force "verify required", it seems, which was a bit surprising.
I had to look at the code in to figure out for sure that this was what happened :)

Actions #4

Updated by Pi Ba almost 7 years ago

Could you checkout 0.17 package?(or perhaps 0.18) I've changed the 'none' CA to a separate checkbox which probably makes more sense (with config convert code in place for that.).. Also the ssl_c_used and required value for checking a valid certificate have been changed. No more duplicate acl's should be written as well..

I'm kinda hoping its now 'mostly' feature complete and features present work properly to copy it to a 'stable' version.

Thanks for the feedback.

Actions #5

Updated by Stéphane Lapie almost 7 years ago

Quick question, what is the proper way to install a development package?
The interface only allows me to install up to 1.5.9 v0.16.
I'll gladly test the latest version on my test environment.

As for features, I have created a ticket (#4394) for one little thing that I thought might make HAproxy further complete.
I'd like to hear your opinion if it's no trouble.

Thanks again for your time and the awesome work !

Actions #6

Updated by Pi Ba almost 7 years ago

There is no public 'development' repository to install developing packages from, however the official package repository should have had 0.17 available yesterday, by now it is updated to 0.18. So simply re-installing haproxy-devel package should give you the updated version.. (with no easy way back either..).

Actions #7

Updated by Stéphane Lapie almost 7 years ago

I tested the latest version (had an IPv6 connectivity problem with the packages repository), it works as intended.

Thanks a lot !

Actions #8

Updated by Chris Buechler almost 7 years ago

  • Status changed from New to Resolved

Also available in: Atom PDF