Re: Rotate SSL certificates on reload (SIGHUP) without restart

Hi Tatsuo,

Have there been any further considerations regarding changes to the pgPool
codebase to support SSL certificate rotation on reload?

As DigiCert has announced last year (
https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days)
TLS/SSL certificate lifetimes will be reduced progressively in the coming
years, with the industry moving toward much shorter validity periods. This
makes the current requirement to fully restart the service for certificate
renewal increasingly impractical.

Please let us know whether this enhancement is being considered, or if
there are any plans or timelines for addressing it.

Regards,
Bob

On Fri, Oct 24, 2025 at 6:44 AM Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:

> > Hello,
> >
> > Please consider adding support for rotating SSL certificates on reloading
> > pgpool2 (i.e., sending SIGHUP to the pgpool parent), so that certificate
> > rotations do not require a full service restart. PostgreSQL can pick up
> new
> > certificates on reload/SIGHUP; pgpool currently requires a restart, which
> > causes connection disruptions.
> >
> > *Current behavior:*
> >
> > - Replace certificate/key files used by pgpool (e.g., server.crt,
> > server.key, related CA chain).
> > - Run systemctl reload pgpool2 (send SIGHUP to the pgpool parent).
> > - Observations: Existing and new client connections continue to
> present
> > the old certificate. Only systemctl restart pgpool2 applies the new
> certs
> > (causing connection interruptions).
>
> Yes, that's the current behavior as described in the docs.
>
> > *Expected behavior:*
> >
> > - After systemctl reload pgpool2 / SIGHUP, pgpool should re-read
> > SSL-related configuration (server cert, private key, chain/CA, CRL if
> > configured) and use them for new client connections, without
> requiring a
> > full restart.
>
> Doable but needs major surgery to the SSL subsystem
> (src/utils/pool_ssl.c) as it assumes that SSL configurations are never
> changed until restarting.
>
> > - Existing connections can continue with the old context; only new
> > handshakes should use the updated materials.
>
> Probably doable.
>
> > - If reload fails, log a clear error and keep using the previous
> context
> > to avoid breaking clients.
> > - Consider parity with PostgreSQL’s SIGHUP behavior for certificate
> > reloads where feasible.
>
> Not sure if it's doable. Needs more research on current code.
>
> BTW, PostgreSQL behaves interestingly.
>
> # "server.key" is the correct ssl_key_file.
>
> test=# show ssl_key_file;
> ssl_key_file
> --------------
> server.key
> (1 row)
>
> test=# \q
> t-ishii$ psql -p 11002 -h localhost test
> psql (18.0)
> SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384,
> compression: off, ALPN: postgresql)
> Type "help" for help.
>
> # Change ssl_key_file to "server.key1" which does not exists.
> # and reload
>
> t-ishii$ pg_ctl -D data0 reload
> server signaled
>
> # keep on using SSL connection
>
> t-ishii$ psql -p 11002 -h localhost test
> psql (18.0)
> SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384,
> compression: off, ALPN: postgresql)
> Type "help" for help.
>
> # It seems PostgreSQL keep on using th previous ssl_key_file value,
> # but it shows the new ssl_key_file value.
>
> test=# show ssl_key_file;
> ssl_key_file
> --------------
> server.key1
> (1 row)
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS K.K.
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.sraoss.co.jp
>