ssl_crl_dir

ssl_crl_dir is the PostgreSQL setting that identifies the location of the SSL certificate revocation list directory.

Note

Fact — official short description: “Location of the SSL certificate revocation list directory.”

Identity

Type , Valuestring: Upstream pg_settings type
Context , Valuesighup: Takes effect after configuration reload
Unit , Value—: Raw unit
Range , Value—: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueConnections and Authentication / SSL: Upstream classification
Latest boot value , Value"": empty string

Lifecycle

Fact	Value
First observed	PG14
Present in	PG14–19 Beta 3
Removed in	No
Introduction commit	`f5465fade908` — Allow specifying CRL directory
Commit date	2021-02-18
Discussion	thread 1

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG14–19 Beta 3	`""`	—	empty string

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.

Tuning advice

Tip

Advice. These are workload-specific starting points and must be validated with measurements.

Workload	Guidance
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.
OLAP	Analytical certificates use the same revocation repository. Do not create a separate stale directory merely because those clients connect less often.
Small nodes	Keep the directory empty unless automated CRL retrieval, rehashing, expiry monitoring, and failover synchronization are in place; an unmaintained directory creates false assurance.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Template	Effective value	Versus upstream boot	Source expression
OLTP	Unmodified	—	—
OLAP	Unmodified	—	—
CRIT	Unmodified	—	—
TINY	Unmodified	—	—

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG14–19 Beta 3 unmodified; OLAP: PG14–19 Beta 3 unmodified; CRIT: PG14–19 Beta 3 unmodified; TINY: PG14–19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

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.

ssl · ssl_cert_file · ssl_key_file · ssl_ca_file · ssl_crl_file · ssl_min_protocol_version