Re: Old style OCSP not working anymore?
On Mon, Jul 24, 2023 at 07:21:16AM +, Jarno Huuskonen wrote:
> Hello,
>
> On Fri, 2023-07-21 at 17:31 +0200, Remi Tricot-Le Breton wrote:
> > I found the faulty commit for Jarno's issue ("cc346678d MEDIUM: ssl: Add
> > ocsp_certid in ckch structure and discard ocsp buffer early").
> > Here's a patch that should fix it. If you want to try it with your
> > setups be my guests, otherwise it should be merged soon if William is ok
> > with the patch.
>
> Thanks Remi. Haproxy-2.8.1 + patch and haproxy returns OCSP response for
> both binds.
>
> -Jarno
>
Thanks Jano and Rémi, I just merged the patch to master, it will be
available in 2.8.2.
--
William Lallemand
Re: Old style OCSP not working anymore?
Hello,
On Fri, 2023-07-21 at 17:31 +0200, Remi Tricot-Le Breton wrote:
> I found the faulty commit for Jarno's issue ("cc346678d MEDIUM: ssl: Add
> ocsp_certid in ckch structure and discard ocsp buffer early").
> Here's a patch that should fix it. If you want to try it with your
> setups be my guests, otherwise it should be merged soon if William is ok
> with the patch.
Thanks Remi. Haproxy-2.8.1 + patch and haproxy returns OCSP response for
both binds.
-Jarno
--
Jarno Huuskonen
Re: Old style OCSP not working anymore?
Hello,
On 21/07/2023 14:40, Remi Tricot-Le Breton wrote:
Hello,
On 21/07/2023 11:51, Jarno Huuskonen wrote:
Hi,
On Thu, 2023-07-20 at 20:27 +0200, Sander Klein wrote:
The best thing to do is to test with `openssl s_client -showcerts
-connect some.hostname.nl:443` with both your versions to identify
what
changed.
I've tested with 'openssl s_client -showcerts -connect mydomain.com:443
-servername mydomain.com -status -tlsextdebug''
Does 2.8.1 send ocsp response if you connect with ipv4 address:
openssl s_client -showcerts -connect ipaddress:443 ...
(with or without -servername)
On 2.6.14 I get an OCSP response, on 2.8.1 I get:
"OCSP response: no response sent"
It really looks like HAProxy doesn't want to send the response coming
from the file. Is there any more information I can gather?
I get the same result as Sander (2.6.x sends ocsp and 2.8.1 doesn't).
I've
ipv4 and ipv6 binds and for ipv4 connection haproxy(2.8.1) sends ocsp
and
for ipv6 it doesn't.
bind ipv4@:443 name v4ssl ssl crt-list /etc/haproxy/ssl/example.crtlist
bind ipv6@:::443 name v6ssl ssl crt-list
/etc/haproxy/ssl/example.crtlist
(And example.crtlist:
/etc/haproxy/ssl/somecertfile.pem.ecdsa [alpn h2,http/1.1]
)
(and somecertfile.pem.ecdsa.ocsp in /etc/haproxy/ssl)
If I change the order of ipv4 / ipv6 binds (so bind ipv6@:::443 name
v6ssl... is first) then haproxy(2.8.1) sends ocsp with ipv6
connection and
not with ipv4.
I found the faulty commit for Jarno's issue ("cc346678d MEDIUM: ssl: Add
ocsp_certid in ckch structure and discard ocsp buffer early").
Here's a patch that should fix it. If you want to try it with your
setups be my guests, otherwise it should be merged soon if William is ok
with the patch.
Sorry for the inconvenience and thanks again for the reproducer Jarno.
Rémi
From 52057496684b3803732a2e263d21f75d71964d3c Mon Sep 17 00:00:00 2001
From: Remi Tricot-Le Breton
Date: Fri, 21 Jul 2023 17:21:15 +0200
Subject: [PATCH] BUG/MINOR: ssl: OCSP callback only registered for first
SSL_CTX
If multiple SSL_CTXs use the same certificate that has an OCSP response
file on the filesystem, only the first one will have the OCSP callback
set. This bug was introduced by "cc346678d MEDIUM: ssl: Add ocsp_certid
in ckch structure and discard ocsp buffer early" which cleared the
ocsp_response from the ckch_data after it was inserted in the tree,
which prevented subsequent contexts from having the callback registered.
This patch should be backported to 2.8.
---
src/ssl_sock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index 9f48483d9..42a76fbb1 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -1132,7 +1132,7 @@ static int ssl_sock_load_ocsp(const char *path, SSL_CTX *ctx, struct ckch_data *
/* In case of ocsp update mode set to 'on', this function might be
* called with no known ocsp response. If no ocsp uri can be found in
* the certificate, nothing needs to be done here. */
- if (!data->ocsp_response) {
+ if (!data->ocsp_response && !data->ocsp_cid) {
if (data->ocsp_update_mode != SSL_SOCK_OCSP_UPDATE_ON || b_data(ocsp_uri) == 0) {
ret = 0;
goto out;
--
2.34.1
Re: Old style OCSP not working anymore?
Hello, On 21/07/2023 11:51, Jarno Huuskonen wrote: Hi, On Thu, 2023-07-20 at 20:27 +0200, Sander Klein wrote: The best thing to do is to test with `openssl s_client -showcerts -connect some.hostname.nl:443` with both your versions to identify what changed. I've tested with 'openssl s_client -showcerts -connect mydomain.com:443 -servername mydomain.com -status -tlsextdebug'' Does 2.8.1 send ocsp response if you connect with ipv4 address: openssl s_client -showcerts -connect ipaddress:443 ... (with or without -servername) On 2.6.14 I get an OCSP response, on 2.8.1 I get: "OCSP response: no response sent" It really looks like HAProxy doesn't want to send the response coming from the file. Is there any more information I can gather? I get the same result as Sander (2.6.x sends ocsp and 2.8.1 doesn't). I've ipv4 and ipv6 binds and for ipv4 connection haproxy(2.8.1) sends ocsp and for ipv6 it doesn't. bind ipv4@:443 name v4ssl ssl crt-list /etc/haproxy/ssl/example.crtlist bind ipv6@:::443 name v6ssl ssl crt-list /etc/haproxy/ssl/example.crtlist (And example.crtlist: /etc/haproxy/ssl/somecertfile.pem.ecdsa [alpn h2,http/1.1] ) (and somecertfile.pem.ecdsa.ocsp in /etc/haproxy/ssl) If I change the order of ipv4 / ipv6 binds (so bind ipv6@:::443 name v6ssl... is first) then haproxy(2.8.1) sends ocsp with ipv6 connection and not with ipv4. Thanks for the extra info, I seem to have a reproducer. I'll look into it and hopefully fixing it will fix Sander's issue as well. Rémi
Re: Old style OCSP not working anymore?
On 2023-07-21 11:51, Jarno Huuskonen wrote: If I change the order of ipv4 / ipv6 binds (so bind ipv6@:::443 name v6ssl... is first) then haproxy(2.8.1) sends ocsp with ipv6 connection and not with ipv4. Hmmm, I cannot reproduce this, but this might be because I have multiple frontends with multiple bind statements. Would be funny if only the first bind statement works in the first frontend. Sander
Re: Old style OCSP not working anymore?
Hi, On Thu, 2023-07-20 at 20:27 +0200, Sander Klein wrote: > > The best thing to do is to test with `openssl s_client -showcerts > > -connect some.hostname.nl:443` with both your versions to identify what > > changed. > > I've tested with 'openssl s_client -showcerts -connect mydomain.com:443 > -servername mydomain.com -status -tlsextdebug'' > Does 2.8.1 send ocsp response if you connect with ipv4 address: openssl s_client -showcerts -connect ipaddress:443 ... (with or without -servername) > On 2.6.14 I get an OCSP response, on 2.8.1 I get: > > "OCSP response: no response sent" > > It really looks like HAProxy doesn't want to send the response coming > from the file. Is there any more information I can gather? I get the same result as Sander (2.6.x sends ocsp and 2.8.1 doesn't). I've ipv4 and ipv6 binds and for ipv4 connection haproxy(2.8.1) sends ocsp and for ipv6 it doesn't. bind ipv4@:443 name v4ssl ssl crt-list /etc/haproxy/ssl/example.crtlist bind ipv6@:::443 name v6ssl ssl crt-list /etc/haproxy/ssl/example.crtlist (And example.crtlist: /etc/haproxy/ssl/somecertfile.pem.ecdsa [alpn h2,http/1.1] ) (and somecertfile.pem.ecdsa.ocsp in /etc/haproxy/ssl) If I change the order of ipv4 / ipv6 binds (so bind ipv6@:::443 name v6ssl... is first) then haproxy(2.8.1) sends ocsp with ipv6 connection and not with ipv4. -Jarno -- Jarno Huuskonen
Re: Old style OCSP not working anymore?
On Thu, Jul 20, 2023 at 08:27:08PM +0200, Sander Klein wrote: > On 2023-07-20 11:14, William Lallemand wrote: > > On Thu, Jul 20, 2023 at 10:23:21AM +0200, Sander Klein wrote: > >> On 2023-07-19 11:00, William Lallemand wrote: > >> "show ssl ocsp-resonse" gives me a lot of output like: > >> > >> Certificate ID key : *LONGID* > >> Certificate path : /parth/to/cert.pem > >> Certificate ID: > >> Issuer Name Hash: *HASH* > >> Issuer Key Hash: *ANOTHERHASH* > >> Serial Number: *SERIAL* > >> > > > > You should check with the path argument so it gives you the date and > > status. > > Okay, so, on HAProxy 2.8.1 with the path argument I get a correct > response: > > OCSP Response Data: > OCSP Response Status: successful (0x0) > Response Type: Basic OCSP Response > Version: 1 (0x0) > Responder Id: C = US, O = Let's Encrypt, CN = R3 > Produced At: Jul 18 07:22:00 2023 GMT > Responses: > Certificate ID: >Hash Algorithm: sha1 >Issuer Name Hash: 48DAC9A0FB2BD32D4FF0DE68D2F567B735F9B3C4 >Issuer Key Hash: 142EB317B75856CBAE500940E61FAF9D8B14C2C6 >Serial Number: 0323CDB93D804581B31A8D0CB737AD57728D > Cert Status: good > This Update: Jul 18 07:00:00 2023 GMT > Next Update: Jul 25 06:59:58 2023 GMT > > Signature Algorithm: sha256WithRSAEncryption > 37:d6:5a:2a:f8:b6:36:a7:5b:b8:1a:7b:24:39:a4:33:61:b7: > 68:85:50:bf:5f:cd:e7:17:1b:9b:cb:c5:fa:31:60:ad:96:71: > f3:39:aa:09:f1:d2:5f:fa:d1:29:a6:3e:27:75:b7:f4:68:7b: > 83:d1:00:7d:e5:52:63:52:56:0f:a3:9c:1c:49:92:1b:a9:6a: > f5:3d:0a:e0:73:8d:ed:89:4b:19:b9:ad:17:7d:ca:f3:bc:3e: > 6d:5f:7c:37:95:f2:50:2f:a2:ed:14:e4:eb:15:dd:7b:eb:93: > 0e:17:62:cb:14:6b:1c:41:6a:07:ba:9b:58:33:c0:5b:5d:32: > c3:f6:ad:c7:a7:42:b7:a2:6e:f0:fd:8c:94:d0:e4:87:bf:fa: > 9c:79:19:fd:54:d8:40:2a:71:6d:9b:f4:1f:42:78:fa:d1:5c: > ac:66:46:c6:2e:59:a3:b1:f1:42:3b:e8:91:6a:85:1d:eb:7d: > 12:da:0f:35:8f:99:50:13:fa:91:08:25:a9:83:f0:c2:a9:d3: > 71:f2:85:5f:3e:65:0e:93:ab:d0:39:89:49:b7:02:01:56:de: > e9:2d:4c:17:e4:58:a2:ea:b0:d0:66:74:a5:ac:91:2e:4f:e0: > 1f:bf:f8:b9:ac:99:32:17:94:9a:0a:ac:e6:78:d9:73:9a:01: > f2:1d:75:82 > > >> Jul 20 10:14:30 some.hostname.nl haproxy[452783]: x.x.x.x:54404 > >> [20/Jul/2023:10:14:30.375] cluster1-in/3: SSL handshake failure > >> (error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad > >> certificate) > >> > > > > This message could be a lot of things, a wrongly generated certificate, > > unsupported signature algorithms, incorrect chain... > > They are plain lets encrypt certificates created with acme.sh and with > ocsp must-staple enabled. Moreover, they work in 2.6.14. > > >> Downgrading to 2.6.14 fixes it again. > > > > I don't see why it would change like this, did you change the openssl > > version linked to haproxy? Recent distribution restrained some old > > algorithms and that could be a problem. We didn't changed much things > > in > > the loading between 2.6 and 2.8 so I'm not seeing why the behavior > > changed. > > The packages I use are the Debian 11 packages from Vincent Bernat. > Looking at the ldd output, nothing has changed. Also no libraries are > changed/upgraded when HAProxy is upgraded. > > > The best thing to do is to test with `openssl s_client -showcerts > > -connect some.hostname.nl:443` with both your versions to identify what > > changed. > > I've tested with 'openssl s_client -showcerts -connect mydomain.com:443 > -servername mydomain.com -status -tlsextdebug'' > > On 2.6.14 I get an OCSP response, on 2.8.1 I get: > > "OCSP response: no response sent" > > It really looks like HAProxy doesn't want to send the response coming > from the file. Is there any more information I can gather? > I'm CCing Remi which worked on this, something could have been broken when doing the ocsp-updater. -- William Lallemand
Re: Old style OCSP not working anymore?
On 2023-07-20 11:14, William Lallemand wrote: On Thu, Jul 20, 2023 at 10:23:21AM +0200, Sander Klein wrote: On 2023-07-19 11:00, William Lallemand wrote: "show ssl ocsp-resonse" gives me a lot of output like: Certificate ID key : *LONGID* Certificate path : /parth/to/cert.pem Certificate ID: Issuer Name Hash: *HASH* Issuer Key Hash: *ANOTHERHASH* Serial Number: *SERIAL* You should check with the path argument so it gives you the date and status. Okay, so, on HAProxy 2.8.1 with the path argument I get a correct response: OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: C = US, O = Let's Encrypt, CN = R3 Produced At: Jul 18 07:22:00 2023 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: 48DAC9A0FB2BD32D4FF0DE68D2F567B735F9B3C4 Issuer Key Hash: 142EB317B75856CBAE500940E61FAF9D8B14C2C6 Serial Number: 0323CDB93D804581B31A8D0CB737AD57728D Cert Status: good This Update: Jul 18 07:00:00 2023 GMT Next Update: Jul 25 06:59:58 2023 GMT Signature Algorithm: sha256WithRSAEncryption 37:d6:5a:2a:f8:b6:36:a7:5b:b8:1a:7b:24:39:a4:33:61:b7: 68:85:50:bf:5f:cd:e7:17:1b:9b:cb:c5:fa:31:60:ad:96:71: f3:39:aa:09:f1:d2:5f:fa:d1:29:a6:3e:27:75:b7:f4:68:7b: 83:d1:00:7d:e5:52:63:52:56:0f:a3:9c:1c:49:92:1b:a9:6a: f5:3d:0a:e0:73:8d:ed:89:4b:19:b9:ad:17:7d:ca:f3:bc:3e: 6d:5f:7c:37:95:f2:50:2f:a2:ed:14:e4:eb:15:dd:7b:eb:93: 0e:17:62:cb:14:6b:1c:41:6a:07:ba:9b:58:33:c0:5b:5d:32: c3:f6:ad:c7:a7:42:b7:a2:6e:f0:fd:8c:94:d0:e4:87:bf:fa: 9c:79:19:fd:54:d8:40:2a:71:6d:9b:f4:1f:42:78:fa:d1:5c: ac:66:46:c6:2e:59:a3:b1:f1:42:3b:e8:91:6a:85:1d:eb:7d: 12:da:0f:35:8f:99:50:13:fa:91:08:25:a9:83:f0:c2:a9:d3: 71:f2:85:5f:3e:65:0e:93:ab:d0:39:89:49:b7:02:01:56:de: e9:2d:4c:17:e4:58:a2:ea:b0:d0:66:74:a5:ac:91:2e:4f:e0: 1f:bf:f8:b9:ac:99:32:17:94:9a:0a:ac:e6:78:d9:73:9a:01: f2:1d:75:82 Jul 20 10:14:30 some.hostname.nl haproxy[452783]: x.x.x.x:54404 [20/Jul/2023:10:14:30.375] cluster1-in/3: SSL handshake failure (error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate) This message could be a lot of things, a wrongly generated certificate, unsupported signature algorithms, incorrect chain... They are plain lets encrypt certificates created with acme.sh and with ocsp must-staple enabled. Moreover, they work in 2.6.14. Downgrading to 2.6.14 fixes it again. I don't see why it would change like this, did you change the openssl version linked to haproxy? Recent distribution restrained some old algorithms and that could be a problem. We didn't changed much things in the loading between 2.6 and 2.8 so I'm not seeing why the behavior changed. The packages I use are the Debian 11 packages from Vincent Bernat. Looking at the ldd output, nothing has changed. Also no libraries are changed/upgraded when HAProxy is upgraded. The best thing to do is to test with `openssl s_client -showcerts -connect some.hostname.nl:443` with both your versions to identify what changed. I've tested with 'openssl s_client -showcerts -connect mydomain.com:443 -servername mydomain.com -status -tlsextdebug'' On 2.6.14 I get an OCSP response, on 2.8.1 I get: "OCSP response: no response sent" It really looks like HAProxy doesn't want to send the response coming from the file. Is there any more information I can gather? Regards, Sander
Re: Old style OCSP not working anymore?
On Thu, Jul 20, 2023 at 10:23:21AM +0200, Sander Klein wrote: > On 2023-07-19 11:00, William Lallemand wrote: > > On Mon, Jul 17, 2023 at 08:12:59PM +0200, Sander Klein wrote: > >> On 2023-07-17 15:17, William Lallemand wrote: > >> > On Thu, Jul 13, 2023 at 05:01:06PM +0200, Sander Klein wrote: > >> >> Hi, > >> >> > >> >> I tried upgrading from 2.6.14 to 2.8.1, but after the upgrade I > >> >> couldn't > >> >> connect to any of the sites behind it. > >> >> > >> >> While looking at the error it seems like OCSP is not working anymore. > >> >> Right now I have a setup in which I provision the certificates with > >> >> the > >> >> corresponding ocsp file next to it. If this not supported anymore? > >> > > >> > This is supposed to still be working, however we could have introduced > >> > bugs when building the ocsp-update. Are you seeing errors during the > >> > OCSP file loading? > >> > >> I don't see any errors, not even when I start haproxy by hand with > >> '-d'. > >> It's just like the ocsp isn't used at al. Also started haproxy with > >> strace attached and I see the ocsp files are loaded. > >> > >> Regards, > >> > >> Sander > >> > > > > Did you check with "show ssl ocsp-response" ? > > > > http://docs.haproxy.org/2.8/management.html#show%20ssl%20ocsp-response > > "show ssl ocsp-resonse" gives me a lot of output like: > > Certificate ID key : *LONGID* > Certificate path : /parth/to/cert.pem > Certificate ID: > Issuer Name Hash: *HASH* > Issuer Key Hash: *ANOTHERHASH* > Serial Number: *SERIAL* > You should check with the path argument so it gives you the date and status. > So I guess that's correct. But then I do a request for a site I get: > > Jul 20 10:14:30 some.hostname.nl haproxy[452783]: x.x.x.x:54404 > [20/Jul/2023:10:14:30.375] cluster1-in/3: SSL handshake failure > (error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad > certificate) > This message could be a lot of things, a wrongly generated certificate, unsupported signature algorithms, incorrect chain... > Downgrading to 2.6.14 fixes it again. I don't see why it would change like this, did you change the openssl version linked to haproxy? Recent distribution restrained some old algorithms and that could be a problem. We didn't changed much things in the loading between 2.6 and 2.8 so I'm not seeing why the behavior changed. The best thing to do is to test with `openssl s_client -showcerts -connect some.hostname.nl:443` with both your versions to identify what changed. -- William Lallemand
Re: Old style OCSP not working anymore?
On 2023-07-19 11:00, William Lallemand wrote: On Mon, Jul 17, 2023 at 08:12:59PM +0200, Sander Klein wrote: On 2023-07-17 15:17, William Lallemand wrote: > On Thu, Jul 13, 2023 at 05:01:06PM +0200, Sander Klein wrote: >> Hi, >> >> I tried upgrading from 2.6.14 to 2.8.1, but after the upgrade I >> couldn't >> connect to any of the sites behind it. >> >> While looking at the error it seems like OCSP is not working anymore. >> Right now I have a setup in which I provision the certificates with >> the >> corresponding ocsp file next to it. If this not supported anymore? > > This is supposed to still be working, however we could have introduced > bugs when building the ocsp-update. Are you seeing errors during the > OCSP file loading? I don't see any errors, not even when I start haproxy by hand with '-d'. It's just like the ocsp isn't used at al. Also started haproxy with strace attached and I see the ocsp files are loaded. Regards, Sander Did you check with "show ssl ocsp-response" ? http://docs.haproxy.org/2.8/management.html#show%20ssl%20ocsp-response "show ssl ocsp-resonse" gives me a lot of output like: Certificate ID key : *LONGID* Certificate path : /parth/to/cert.pem Certificate ID: Issuer Name Hash: *HASH* Issuer Key Hash: *ANOTHERHASH* Serial Number: *SERIAL* So I guess that's correct. But then I do a request for a site I get: Jul 20 10:14:30 some.hostname.nl haproxy[452783]: x.x.x.x:54404 [20/Jul/2023:10:14:30.375] cluster1-in/3: SSL handshake failure (error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate) Downgrading to 2.6.14 fixes it again. Sander
Re: Old style OCSP not working anymore?
On Mon, Jul 17, 2023 at 08:12:59PM +0200, Sander Klein wrote: > On 2023-07-17 15:17, William Lallemand wrote: > > On Thu, Jul 13, 2023 at 05:01:06PM +0200, Sander Klein wrote: > >> Hi, > >> > >> I tried upgrading from 2.6.14 to 2.8.1, but after the upgrade I > >> couldn't > >> connect to any of the sites behind it. > >> > >> While looking at the error it seems like OCSP is not working anymore. > >> Right now I have a setup in which I provision the certificates with > >> the > >> corresponding ocsp file next to it. If this not supported anymore? > > > > This is supposed to still be working, however we could have introduced > > bugs when building the ocsp-update. Are you seeing errors during the > > OCSP file loading? > > I don't see any errors, not even when I start haproxy by hand with '-d'. > It's just like the ocsp isn't used at al. Also started haproxy with > strace attached and I see the ocsp files are loaded. > > Regards, > > Sander > Did you check with "show ssl ocsp-response" ? http://docs.haproxy.org/2.8/management.html#show%20ssl%20ocsp-response -- William Lallemand
Re: Old style OCSP not working anymore?
On 2023-07-17 15:17, William Lallemand wrote: On Thu, Jul 13, 2023 at 05:01:06PM +0200, Sander Klein wrote: Hi, I tried upgrading from 2.6.14 to 2.8.1, but after the upgrade I couldn't connect to any of the sites behind it. While looking at the error it seems like OCSP is not working anymore. Right now I have a setup in which I provision the certificates with the corresponding ocsp file next to it. If this not supported anymore? This is supposed to still be working, however we could have introduced bugs when building the ocsp-update. Are you seeing errors during the OCSP file loading? I don't see any errors, not even when I start haproxy by hand with '-d'. It's just like the ocsp isn't used at al. Also started haproxy with strace attached and I see the ocsp files are loaded. Regards, Sander
Re: Old style OCSP not working anymore?
On Thu, Jul 13, 2023 at 05:01:06PM +0200, Sander Klein wrote: > Hi, > > I tried upgrading from 2.6.14 to 2.8.1, but after the upgrade I couldn't > connect to any of the sites behind it. > > While looking at the error it seems like OCSP is not working anymore. > Right now I have a setup in which I provision the certificates with the > corresponding ocsp file next to it. If this not supported anymore? > > Regards, > > Sander > This is supposed to still be working, however we could have introduced bugs when building the ocsp-update. Are you seeing errors during the OCSP file loading? -- William Lallemand
Re: Old style OCSP not working anymore?
Hi, On 2023-07-14 01:56, Shawn Heisey wrote: On 7/13/23 09:01, Sander Klein wrote: I tried upgrading from 2.6.14 to 2.8.1, but after the upgrade I couldn't connect to any of the sites behind it. While looking at the error it seems like OCSP is not working anymore. Right now I have a setup in which I provision the certificates with the corresponding ocsp file next to it. If this not supported anymore? Does your certificate have "must-staple" configured? That is the only way I can imagine an OCSP problem would keep websites from working. I do ocsp stapling with haproxy, but I don't use "must-staple". I do not believe that ocsp stapling is supported widely enough yet to declare that it MUST happen. Yes I do have must-staple enabled, but I also update regularly and restart HAProxy. The thing is, with HAProxy 2.8.1 it doesn't work at all anymore. Not even with fresh ocsp files and a fresh restart. I uploaded a script to github. This is the script I used before haproxy gained the ability to do its own OCSP updates. The script updates the .ocsp file(s) and informs haproxy about the new response(s) so haproxy does not need to be restarted.: https://github.com/elyograg/haproxy-ocsp-elyograg The script relies on mktemp, openssl, socat, and base64. I can have a look at this, but I think I have about the same setup right now. Sander
Re: Old style OCSP not working anymore?
On 7/13/23 17:56, Shawn Heisey wrote: I do still use this script on one of my servers where I can't get haproxy's built-in ocsp updating to work right. It is haproxy 2.8.1. A few minutes ago, I fixed the problem on that server with haproxy's built-in OCSP updater, so the script is officially retired. Thanks, Shawn
Re: Old style OCSP not working anymore?
On 7/13/23 09:01, Sander Klein wrote: I tried upgrading from 2.6.14 to 2.8.1, but after the upgrade I couldn't connect to any of the sites behind it. While looking at the error it seems like OCSP is not working anymore. Right now I have a setup in which I provision the certificates with the corresponding ocsp file next to it. If this not supported anymore? Does your certificate have "must-staple" configured? That is the only way I can imagine an OCSP problem would keep websites from working. I do ocsp stapling with haproxy, but I don't use "must-staple". I do not believe that ocsp stapling is supported widely enough yet to declare that it MUST happen. If you are relying only on the .ocsp file and are not informing haproxy when there is a new response, then you have to restart (or maybe reload) haproxy when you update the ocsp file. If you don't, then the ocsp response that haproxy is using will quickly expire in a matter of days, as the .ocsp file is only read at startup. I uploaded a script to github. This is the script I used before haproxy gained the ability to do its own OCSP updates. The script updates the .ocsp file(s) and informs haproxy about the new response(s) so haproxy does not need to be restarted.: https://github.com/elyograg/haproxy-ocsp-elyograg The script relies on mktemp, openssl, socat, and base64. I do still use this script on one of my servers where I can't get haproxy's built-in ocsp updating to work right. It is haproxy 2.8.1. Thanks, Shawn
Old style OCSP not working anymore?
Hi, I tried upgrading from 2.6.14 to 2.8.1, but after the upgrade I couldn't connect to any of the sites behind it. While looking at the error it seems like OCSP is not working anymore. Right now I have a setup in which I provision the certificates with the corresponding ocsp file next to it. If this not supported anymore? Regards, Sander
