| From: | Renaud Métrich <rmetrich(at)redhat(dot)com> |
|---|---|
| To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [PATCH v4] Add ssl_cert_files/ssl_key_files for multi-certificate support |
| Date: | 2026-09-08 13:50:40 |
| Message-ID: | 71d107c9-b5b5-4d53-b729-e6d9825f2a12@redhat.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
Could someone check this new feature (patch in previous mail).
Best regards,
Renaud.
Le 24/06/2026 à 3:24 PM, Renaud Métrich a écrit :
> 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.
>>
>>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ayush Tiwari | 2026-09-08 13:58:51 | Re: Concurrent DROP TABLESPACE can miss a shared dependency |
| Previous Message | Tom Lane | 2026-09-08 13:48:21 | Re: docs: Fixes for August 2026 minor release notes (v14-v17) |