ssl_crl_dir

Definition PG 18 manual

Specifies the name of the directory containing the SSL client certificate revocation list (CRL). Relative paths are relative to the data directory. This parameter can only be set in the postgresql.conf file or on the server command line. The default is empty, meaning no CRLs are used (unless ssl_crl_file is set).

The directory needs to be prepared with the OpenSSL command openssl rehash or c_rehash. See its documentation for details.

When using this setting, CRLs in the specified directory are loaded on-demand at connection time. New CRLs can be added to the directory and will be used immediately. This is unlike ssl_crl_file, which causes the CRL in the file to be loaded at server start time or when the configuration is reloaded. Both settings can be used together.

How it works

ssl_crl_dir names a directory of client-certificate revocation lists. OpenSSL requires hashed lookup links, so the directory must be prepared again with openssl rehash or c_rehash whenever CRLs are added or replaced. It supplements ssl_crl_file; both sources can be active.

Changing the directory path is a SIGHUP-context configuration change, but CRL files inside the configured directory are loaded on demand at connection time. A newly installed and correctly rehashed CRL can therefore be used immediately by new connections without a PostgreSQL reload.

This differs from ssl_crl_file, whose file content is loaded at server startup or configuration reload. Existing TLS sessions are not retroactively revoked by either setting; test revocation with a fresh client-certificate handshake and monitor CRL issuer, signature, and expiry.

Operational considerations

Adding or replacing a CRL without running openssl rehash or c_rehash, leaving it undiscoverable by OpenSSL.

Reloading PostgreSQL but not refreshing an expired CRL, or assuming a directory change applies retroactively to established TLS sessions.

Treating ssl_crl_dir like ssl_crl_file and missing that directory CRLs are loaded on demand for new connections.

Synchronizing the directory path but not its CRLs and hash links to every failover node.

Workload guidance

OLAP: Analytical certificates use the same revocation repository. Do not create a separate stale directory merely because those clients connect less often.

OLTP: Manage ssl_crl_dir as an issuer-indexed CRL repository: add current CRLs, run openssl rehash or c_rehash, and test revocation with a new connection. Use it when on-demand multi-issuer updates are operationally maintained.

SMALL: Keep the directory empty unless automated CRL retrieval, rehashing, expiry monitoring, and failover synchronization are in place; an unmaintained directory creates false assurance.