Thanks, this is what I was looking for. I could just call a reload of the
LB with the PID whenever the CRL was updated by the cron.

Is there a requirement to bind on 443 for this method or can I make it
anything?

Adding the header info with the details from the client will require a
backend server side change to now check the headers for this information or
is it the default location and should appear like hitting the server
directly? I am going to test just to verify the results.

Thanks again for the help.

Sam

On February 18, 2017 at 2:33:41 AM, Daniel Schneller (
daniel.schnel...@centerdevice.com) wrote:

> Damn. I shouldn't respond to questions after midnight :-(. I completely
> overread this is about client certificates until now. Sorry for missing
> that, Sam; and thanks Willy for the interesting link.
>
> One question comes up for me though, after reading it (unless I am still
> not awake enough, in which case I apologize upfront). The article contains
> instructions about a cron job to periodically fetch a CRL and put it in the
> place where haproxy expects it. But doesn't haproxy load the file just once
> on startup? Would replacing it like that even be noticed?
>
> Daniel
>
> On 18 Feb 2017, at 07:28, Willy Tarreau <w...@1wt.eu> wrote:
>
> On Fri, Feb 17, 2017 at 07:20:14PM -0500, Sam Crowell wrote:
> Thanks for the response Daniel. What is the best way to handle SSL traffic
> through a load balancer to maintain original client certificates? Just use
> mode TCP and passthrough? Is there a way to do that without turning off
> hostname verifier at the client level?
>
>
> If you want to transfer client certificates to the server, you have to
> pass them in HTTP headers or using the proxy protocol for non-HTTP
> services. This means that you'll rely on haproxy to validate these
> client certs using the CA and possibly CRL though.
>
> There's a good example here :
>
> https://raymii.org/s/tutorials/haproxy_client_side_ssl_certificates.html
>
> Hoping this helps,
> Willy
>
>

Reply via email to