]> git.ipfire.org Git - thirdparty/haproxy.git/commitdiff
REGTESTS: ssl: fix generate-certificates w/ LibreSSL
authorWilliam Lallemand <wlallemand@haproxy.com>
Wed, 21 Jan 2026 15:40:21 +0000 (16:40 +0100)
committerWilliam Lallemand <wlallemand@haproxy.com>
Wed, 21 Jan 2026 15:50:16 +0000 (16:50 +0100)
Since commit eb5279b15 ("BUG/MEDIUM: ssl: fix generate-certificates
option when SNI greater than 64bytes") the LibreSSL job does not seem to
work anymore.

Indeed the reg-tests was modified to add a SNI longer than 64 bytes,
without any concern about the DNS standard, which allows only 63 bytes
per label.

LibreSSL is stricter than the other libraries about that, and checks
that the SNI is compliant with the DNS RFC in the
tlsext_sni_is_valid_hostname() function
https://github.com/libressl/openbsd/blob/OPENBSD_7_8/src/lib/libssl/ssl_tlsext.c#L710

This patch fixes the issue by splitting the SNI with a second label to
reach more than 64 bytes.

Must be backported with eb5279b15 in every stable branches.

reg-tests/ssl/ssl_generate_certificate.vtc

index 1f758f98a791f23a1a9f31b7a7a7150f84b47201..53f81c780a6a5110cc9946b1d244b5f90efd95d8 100644 (file)
@@ -150,7 +150,7 @@ client c5 -connect ${h1_clearlst_sock} {
 # Use another SNI - the server certificate should be generated and different
 # than the default one
 client c6 -connect ${h1_clearlst_sock} {
-  txreq -url "/P-384" -hdr "x-sni: sni-longer-sni-longer-sni-longer-sni-longer-than-64-bytes-unknown-sni.com"
+  txreq -url "/P-384" -hdr "x-sni: sni-longer-sni-longer-sni-longer.sni-longer-than-64-bytes-unknown-sni.com"
   rxresp
   expect resp.status == 200
   expect resp.http.x-ssl-sig_alg == "ecdsa-with-SHA256"