Re: Problem with crl certificate
Wow, Many thanks!I implement these configurations, I will keep you updated! Best Regards,Domenico Il giorno mar, 21/04/2020 alle 10.19 +0200, William Lallemand ha scritto: > On Tue, Apr 21, 2020 at 10:07:27AM +0200, Domenico Briganti wrote: > > Thanks William, yes, the reload of haproxy is a feasible way, I > > hadn'tnoticed.I have just one doubt, since I update the crl every > > day and Ihave mqtt connections that can stay connected for days, at > > the end Ican have many haproxy process running, one a day, until > > all oldconnection (of that day) terminates. I think that with ps > > and netstatsI can see how many they are and how many old > > connections each processmanages.However I can afford a complete > > restart of haproxy once everytwo/three weeks.Regards,Domenico > > If you configure the master CLI (haproxy -S binary argument), you > willbe able to access to the CLI of the previous process and monitor > theremaining connections. The previous process won't leave until > theconnections aren't closed. > You can force a process to leave even if there are still > someconnections with the directive "hard-stop-after". > https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#3.1-hard-stop-after > > You can also limit the number of workers with the directive"mworker- > max-reloads". > https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#3.1-mworker-max-reloads > > Regards,
Re: Problem with crl certificate
On Tue, Apr 21, 2020 at 10:07:27AM +0200, Domenico Briganti wrote: > 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 If you configure the master CLI (haproxy -S binary argument), you will be able to access to the CLI of the previous process and monitor the remaining connections. The previous process won't leave until the connections aren't closed. You can force a process to leave even if there are still some connections with the directive "hard-stop-after". https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#3.1-hard-stop-after You can also limit the number of workers with the directive "mworker-max-reloads". https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#3.1-mworker-max-reloads Regards, -- William Lallemand
Re: Problem with crl certificate
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,
Re: Problem with crl certificate
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 of > the file passed to crl-file parameter, thant contein already the > intermediate crl. > But now we have another challenges, but we're going to loose this time > as already discussed in [1] and [2]. > We proxy MQTT connections, and wa can't afford a restart of haproxy > every 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 a problem. 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 have impact on your service. There is currently some active development on the CLI for pushing certificates on-the-fly, the CRL is not available for this yet, but could be added in the future. Regards, -- William Lallemand
Re: Problem with crl certificate
Ciao Marco, thanks for your help. We've found the problem, we do need also the CRL from ROOT CA on top of the file passed to crl-file parameter, thant contein already the intermediate crl. But now we have another challenges, but we're going to loose this time as already discussed in [1] and [2]. We proxy MQTT connections, and wa can't afford a restart of haproxy every 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 Il giorno sab, 18/04/2020 alle 10.40 +0200, Marco Corte ha scritto: > Hi! > Il 17/04/20 18:43, Davide Guarneri ha scritto: > > crt /etc/haproxy/ssl/cert.pem ca-file /etc/haproxy/ssl/ca- > > chain.cert.pem verify required crl-file > > /etc/haproxy/ssl/intermediate.crl.pem > > I would verify how the certificates and the keys are placed in the > files. > /etc/haproxy/ssl/cert.pem must contain "both the required > certificates and any associated private keys. [...] If your CA > requires an intermediate certificate, this can also be concatenated > into this file." (from HAProxy documentation) > The client certificate is checked against the signature of the CAs > defined in /etc/haproxy/ssl/ca-chain.cert.pem > Moreover it is checked if the client certificate is listed in the > certificate revocation list in /etc/haproxy/ssl/intermediate.crl.pem > Hope this helpsCiao! > .marcoc
Re: Problem with crl certificate
Hi! Il 17/04/20 18:43, Davide Guarneri ha scritto: crt /etc/haproxy/ssl/cert.pem ca-file /etc/haproxy/ssl/ca-chain.cert.pem verify required crl-file /etc/haproxy/ssl/intermediate.crl.pem I would verify how the certificates and the keys are placed in the files. /etc/haproxy/ssl/cert.pem must contain "both the required certificates and any associated private keys. [...] If your CA requires an intermediate certificate, this can also be concatenated into this file." (from HAProxy documentation) The client certificate is checked against the signature of the CAs defined in /etc/haproxy/ssl/ca-chain.cert.pem Moreover it is checked if the client certificate is listed in the certificate revocation list in /etc/haproxy/ssl/intermediate.crl.pem Hope this helps Ciao! .marcoc
Problem with crl certificate
Hello everyone, I'm trying to setup haproxy to handle TLS request with mutual authentication and CRL, here's an extract of the current configuration: ``` frontend mqtts_frontend bind *:8883 ssl crt /etc/haproxy/ssl/cert.pem ca-file /etc/haproxy/ssl/ca-chain.cert.pem verify required crl-file /etc/haproxy/ssl/intermediate.crl.pem default_backend mqtts_backend backend mqtts_backend server mqtt1 mqtt1:1884 check send-proxy server mqtt2 mqtt2:1884 check send-proxy ``` Those certificates are working with my current apache setup, when i test with openssl everything is working: Verify return code: 0 (ok) The problem is that when I test against the haproxy i receive the following error Verify return code: 19 (self signed certificate in certificate chain). If I remove the "crl-file /etc/haproxy/ssl/ca.crl.pem" everything goes OK, but I need to handle the revocate clients. The chain of server certificate is: CARoot -> Intermediate -> Server The clients have a certificate signed also by Intermediate. And also cert CRL is signed by Intermediate. Have you any suggestions? Thanks, Davide
