Re: [PATCH v4] Add ssl_cert_files/ssl_key_files for multi-certificate support

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.
>>
>>

In response to

Responses

Browse pgsql-hackers by date

  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)