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 <rlebre...@haproxy.com>
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

Reply via email to