Opportunistic client certificate validation

Help!
1

Greetings,

I have an application that authenticates its peers using pre-registered self-signed certificates. When we deploy this application behind a nginx or apache reverse proxy, we use TLS client authentication with “optional_no_ca” and transfer the hash of the certificate to the application using a custom header.

Now I’d like to deploy this application behind HAproxy. Using “verify optional” in combination with “crt-ignore-err all” seems to be the right choice, but it seems HAproxy provides an empty value for %[ssl_c_sha1] upon authentication. This might make sense when you actually require certificate validation, but in this case ANY certificate is valid for the reverse proxy.

There are examples of how to do certificate validation in the application, but I’ve seen none that uses self-signed certificates.

Is there any way to configure HAproxy to not only accept the self-signed certificate and also make data extracted from the client certificate available? Adding an “optional_no_ca” mode with the same semantics as nginx and apache make sense, but perhaps there are other options. Please advise.

2

No one else having this problem?

3

Not something I’ve bumped up against… Am I right in guessing that you provide no ca-file?

If so then provide one, any one… Basically, I just did a quick test in my lab and I used an old cert from a previous test against my current CA, this is the result:

GET /secure/index.html HTTP/1.1
User-Agent: curl/7.41.0
Host: 172.16.200.85
Accept: /
X-SSL: 1
X-SSL-Client-Verify: 21
X-SSL-Client-SHA1: …I.%01%19.’.9…>…%04

I got my SHA1 header and the connection was successful as I used “verify optional” and “crt-ignore-err all” as you suggest, I just got a client verify of 21, does your backend use the client verify output? if not then I suspect any CA will act as a workaround.