I also like the concept of .libprc. But if we think about it within the current state of configuration: let's say the user doesn't want to specify a CRL file, even in the default location (~/.postgresql/root.crl), we, as the client-side of PostgreSQL, have no right to refuse a connection to the database server. In that case, would it be correct to log that the user didn't specify a CRL file (even in (~/.postgresql/root.crl))?

The idea of the patch is to ensure that the client-side performs stricter configuration checking for CRL files than it currently does.

Michael

----------------

Кому: Михаил Купцов (mr.cuptsov2018@yandex.ru);

Копия: pgsql-hackers@lists.postgresql.org;

Тема: Changing client-side behavior regarding Certificate Revocation Lists (CRL);

25.08.2026, 15:08, "Daniel Gustafsson" <daniel@yesql.se>:

On 24 Aug 2026, at 17:34, Михаил Купцов <mr.cuptsov2018@yandex.ru> wrote:

I would like to propose a different approach regarding the client side behavior
in terms of working with the list of revoked certificates. The problem that
was discovered is that if a user, using psql, accidentally specifies an
incorrect path to a crl file or crl directory, the client part of Postgres
ignores the user's error and connects the client to the database whose
certificate the client would, in theory, want to check whether the database
server certificate has been revoked.

I'm sympathetic to the idea of helping the user detect misconfiguration.
However, I wonder how common it is to have a "local default" filename
configured in apps which may or may not be present. If those users all of a
sudden cannot connect after an upgrade then we didn't really improve anything.

Also, with this patch, users who have placed their CRL to match the default CRL
file location (~/.postgresql/root.crl) won't get an error if that file is
missing even if their intention was to use that file.

I think a stricter CRL policy would need another trigger.

--
Daniel Gustafsson