Hi, I would like to setup haproxy as our backend LB. We have a self certificate on client side. The client will use the certificate to connect the haproxy. We would like to use OCSP rather than CRL on haproxy to verify the certificate. How should I do.
I found online about the information. But it seems all about the OCSP stapling on haproxy, which is not what we know. We want to verify certificate coming from client by haproxy. Where should I do the configuration
What’s the reason you want to use OCSP instead of CRL?
OCSP for client certificates would mean that HAProxy has to block the request, fire up a HTTP request to the OCSP server containing the revocation list and only then verify the client certificate.
This is something a browser can when talking to a HTTPS Server, but certainly doesn’t scale on a HTTPS Server/Proxy for client certificates.
Problem is Mozilla is recommending that you do stapling in server sw, otherwise it is possible to track user via browser OCSP requests. We(hosting provider) allready have to do this for some certs (having separate process that does stapling on behalf of haproxy), but in long term it would need to be implemented in haproxy (https://tools.ietf.org/html/rfc7633 in affect from october last year).
@dz0ny this thread is about something else entirely. It is about OCSP for client certificates.
Haproxy does support OCSP stapling. I doesn’t pull the OCSP response itself, but a helper script can and you would set it up via the admin socket. So haproxy can OCSP staple if you want.
I’d suggest you open a new thread in case additional clarification is needed.
@lukastribus - there are a few good reasons to use this over CRLs.
At this point, I’m looking to overcome all three of those but the first one is kind of the killer for CRLs. We’re probably going to write something in Lua to check status (against a local list) + some external process to sync data over.
@gregory and like I said OCSP stapling is supported. But this thread is about client certificates, so I’m not sure what you are saying?
Yes, I am talking about client certs. When the client cert is validated, the issure cert may have an OCSP endpoint listed. This is the OCSP responder that can be used to validate the certificate. We have 500k client certificates and one CA for all of those.
I see, but I’m not sure if it is a good idea to implement on-the-fly OCSP validation in an event-driven single threaded proxy/webserver.
We would probably block the whole process while we validate OCSP. The SSL handshake already leads to problems in medium/big setups, external OCSP verification is even more problematic. Do you really want to stall all your traffic for seconds while the OCSP validation times out?
I don’t think that’s a good idea, and actually, both Google and Mozilla are going down with a revocation list push approach, Chrome doesn’t actually do OCSP and Google even removed OCSP from boringssl completely.
If you are concerned about memory usage, think about the memory usage of caching your 500k OCSP responses in haproxy and what an attacker can do with the knowledge that your box validates client certificates with OCSP which it of course has to cache.
Yes, to push new CRLs haproxy has to be reloaded, but I’m sure this can be improved, to load refreshed CRL’s like we load refreshed OCSP responses for stapling (via the admin socket [1]).
If you operate your own CA, you can automate the post revocation process and push a CRL to your proxies in minutes. With OCSP you have a fixed timeout; I don’t see how OCSP can be faster, if you properly automate a CRL push to haproxy.
I suggest you post your use case to the mailing list, there are more eyes and ears there.
[1] https://cbonte.github.io/haproxy-dconv/1.7/management.html#9.3-set%20ssl%20ocsp-response
I’m sorry to answer an old discussion.
In some OCSP use cases for client cert. validation is a viable solution. My clients are IoT devices and they use MQTT connections. A connection can stay established even for months, I don’t mind if it takes seconds to connect. With OCSP I can manage client authentication more easly that with CRL.