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 > >
