Hi Zsolt,
I'm very sorry, I messed up my internal GIT when building the patch,
causing "TLS 1.3 HRR test" to be lost, I've added it back to v4, please
search for "Test 6: TLS 1.3 HelloRetryRequest with multi-cert".
---
Regarding "ssl_cert_files", it takes precedence but actually was not
taking full precedence, in the sense that if there was a cert of some
type in "ssl_cert_file" and in "ssl_cert_files" as well, then the one in
"ssl_cert_files" would be used, but if the types were different, then
they were added.
Now with v4 if "ssl_cert_files" is present, then "ssl_cert_file" is
ignored entirely and a warning shows up when starting.
IMHO failing if both "ssl_cert_file" and "ssl_cert_files" are present is
overkill, a warning is sufficient (search for "Test 13: ssl_cert_files
takes precedence over ssl_cert_file").
---
For LibreSSL, the code was weak indeed. It's actually better to fail
when LibreSSL is used and more than one cert is provided.
But actually I don't have LibreSSL at all (I'm on RHEL), so all I did is
set a guard to simulate it.
Now I installed libressl-4.3.1-1.el9 packages and built to confirm all
is fine with it as well.
Test 13, which verifies that "ssl_cert_files" takes precedence over
"ssl_cert_file" now fails with LibreSSL with errors/hints below:
FATAL: ssl_cert_files with multiple entries is not supported by this build
HINT: This build lacks SSL_CTX_set_current_cert() support (e.g.
LibreSSL). Only one certificate can be served.
With such failure, users are aware that using "ssl_cert_files" is mostly
useless for them.
If LibreSSL later adds the missing code, the feature will then work
automagically (the doc will have to be updated however since I added the
sentence "Builds using <productname>LibreSSL</productname> support only
a single entry; ...").
Renaud.
Le 22/06/2026 à 8:40 PM, Zsolt Parragi a écrit :
>> When set, ssl_cert_files takes precedence over ssl_cert_file.
> Are you sure? ssl_cert_files gets loaded after ssl_cert_file was
> already, it seems additive to me. Shouldn't specifying both result in
> an error instead?
>
>> 2) TLS 1.3 HRR test — added a proper test that forces HelloRetryRequest
>> by setting ssl_groups='secp384r1' on the server and connecting with
>> -groups X25519:secp384r1. The ssl_update_ssl() fix (override=1
>> always) is carried over from v2.
> I don't see it? The string secp384r1 doesn't appear in the patch at all.
>
>> LibreSSL fallback
>> paths verified via #undef SSL_CERT_SET_FIRST build.
> I think the fallback part needs at least a proper documentation /
> description specifying what's the expected behavior. Currently if I
> follow it correctly it serves the last loaded certificate, silently
> ignoring others? I don't think that's a behavior I would expect from a
> security-focused feature. But note that I did not try to build the
> patch with libressl and run tests with it yet.
>
>
