Thanks William, yes, the reload of haproxy is a feasible way, I hadn't noticed.I have just one doubt, since I update the crl every day and I have mqtt connections that can stay connected for days, at the end I can have many haproxy process running, one a day, until all old connection (of that day) terminates. I think that with ps and netstats I can see how many they are and how many old connections each process manages.However I can afford a complete restart of haproxy once every two/three weeks. Regards,Domenico
Il giorno mar, 21/04/2020 alle 08.54 +0200, William Lallemand ha scritto: > Hello, > On Mon, Apr 20, 2020 at 03:15:57PM +0200, Domenico Briganti wrote: > > Ciao Marco, thanks for your help.We've found the problem, we do > > need also the CRL from ROOT CA on top ofthe file passed to crl-file > > parameter, thant contein already theintermediate crl.But now we > > have another challenges, but we're going to loose this timeas > > already discussed in [1] and [2].We proxy MQTT connections, and wa > > can't afford a restart of haproxyevery day to force haproxy to take > > the updated CRL...Any help?Regards,Domenico[1] > > https://discourse.haproxy.org/t/crl-reload-and-long-life-tcp-connections/2645/2[2 > > ] > > https://discourse.haproxy.org/t/ssl-termination-fails-when-crl-is-published/2336 > > Indeed a reload of HAProxy is still required, but that shouldn't be > aproblem. With the reload, active connections won't be killed. > You just need to configure the seamless reload by adding the > option"expose-fd listeners" to your stats socket line, this way you > won't haveimpact on your service. > There is currently some active development on the CLI for > pushingcertificates on-the-fly, the CRL is not available for this > yet, butcould be added in the future. > Regards,
