[PATCH 1/2] BUG/MINOR: server-state: Avoid warning on 'file not found'
From: Marcos de Oliveira
On a clean installation, users might want to use server-state-file and
the recommended zero-warning option. This caused a problem if
server-state-file was not found, as a warning was emited, causing
startup to fail.
This will allow users to specify nonexistent server-state-file at first,
and dump states to the file later.
Fixes #2190
---
src/server_state.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/src/server_state.c b/src/server_state.c
index d2cc4d820..93dbd20f1 100644
--- a/src/server_state.c
+++ b/src/server_state.c
@@ -798,7 +798,10 @@ void apply_server_state(void)
errno = 0;
f = fopen(file, "r");
if (!f) {
- ha_warning("config: Can't open global server state file '%s':
%s\n", file, strerror(errno));
+ if (errno == ENOENT)
+ ha_notice("config: Can't open global server state file
'%s': %s\n", file, strerror(errno));
+ else
+ ha_warning("config: Can't open global server state file
'%s': %s\n", file, strerror(errno));
goto no_globalfile;
}
@@ -866,8 +869,12 @@ void apply_server_state(void)
errno = 0;
f = fopen(file, "r");
if (!f) {
- ha_warning("Proxy '%s': Can't open server state file
'%s': %s.\n",
- curproxy->id, file, strerror(errno));
+ if (errno == ENOENT)
+ ha_notice("Proxy '%s': Can't open server state
file '%s': %s.\n",
+ curproxy->id, file, strerror(errno));
+ else
+ ha_warning("Proxy '%s': Can't open server state
file '%s': %s.\n",
+ curproxy->id, file, strerror(errno));
continue; /* next proxy */
}
--
2.25.1
[PATCH 2/2] BUG/MINOR: server-state: Ignore empty files
From: Marcos de Oliveira
Users might want to pre-create an empty file for later dumping
server-states. This commit allows for that by emiting a notice in case
file is empty and a warning if file is not empty, but version is unknown
Fix partially: #2190
---
src/server_state.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/src/server_state.c b/src/server_state.c
index 93dbd20f1..ebdcf3c69 100644
--- a/src/server_state.c
+++ b/src/server_state.c
@@ -522,6 +522,7 @@ static void srv_state_px_update(const struct proxy *px, int
vsn, struct eb_root
/*
* read next line from file and return the server state version if one
found.
+ * If file is empty, then -1 is returned
* If no version is found, then 0 is returned
* Note that this should be the first read on
*/
@@ -532,7 +533,7 @@ static int srv_state_get_version(FILE *f) {
/* first character of first line of the file must contain the version
of the export */
if (fgets(mybuf, SRV_STATE_LINE_MAXLEN, f) == NULL)
- return 0;
+ return -1;
vsn = strtol(mybuf, , 10);
if (endptr == mybuf || *endptr != '\n') {
@@ -806,9 +807,13 @@ void apply_server_state(void)
}
global_vsn = srv_state_get_version(f);
- if (global_vsn == 0) {
- ha_warning("config: Can't get version of the global server
state file '%s'.\n",
- file);
+ if (global_vsn < 1) {
+ if (global_vsn == -1)
+ ha_notice("config: Empty global server state file
'%s'.\n",
+ file);
+ if (global_vsn == 0)
+ ha_warning("config: Can't get version of the global
server state file '%s'.\n",
+ file);
goto close_globalfile;
}
@@ -880,9 +885,13 @@ void apply_server_state(void)
/* first character of first line of the file must contain the
version of the export */
local_vsn = srv_state_get_version(f);
- if (local_vsn == 0) {
- ha_warning("Proxy '%s': Can't get version of the server
state file '%s'.\n",
- curproxy->id, file);
+ if (local_vsn < 1) {
+ if (local_vsn == -1)
+ ha_notice("Proxy '%s': Empty server state file
'%s'.\n",
+ curproxy->id, file);
+ if (local_vsn == 0)
+ ha_warning("Proxy '%s': Can't get version of
the server state file '%s'.\n",
+ curproxy->id, file);
goto close_localfile;
}
--
2.25.1
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
