MIME-Version: 1.0
References: 
 <CAHtZvrddqfbnERYY_DqgURWCjuXeTjM0y08k-ZP_B0bAHYx2ag@mail.gmail.com>
 <20251024.134447.1860326874693905337.ishii@postgresql.org>
In-Reply-To: <20251024.134447.1860326874693905337.ishii@postgresql.org>
From: Bob Ross <bob.ross.19821@gmail.com>
Date: Mon, 16 Mar 2026 10:20:38 +0100
Message-ID: 
 <CAHtZvrdYG5ebRkZF+tZOqOEZ4WMjMjAC8efiKBRKQua2JHpJ9g@mail.gmail.com>
Subject: Re: Rotate SSL certificates on reload (SIGHUP) without restart
To: Tatsuo Ishii <ishii@postgresql.org>
Cc: pgpool-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000107c5d064d20bcf1"
Archived-At: 
 <https://www.postgresql.org/message-id/CAHtZvrdYG5ebRkZF%2BtZOqOEZ4WMjMjAC8efiKBRKQua2JHpJ9g%40mail.gmail.com>
Precedence: bulk

--000000000000107c5d064d20bcf1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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-red=
uce-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=E2=80=AFAM Tatsuo Ishii <ishii@postgresql.org>=
 wrote:

> > Hello,
> >
> > Please consider adding support for rotating SSL certificates on reloadi=
ng
> > pgpool2 (i.e., sending SIGHUP to the pgpool parent), so that certificat=
e
> > rotations do not require a full service restart. PostgreSQL can pick up
> new
> > certificates on reload/SIGHUP; pgpool currently requires a restart, whi=
ch
> > 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 i=
f
> >    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=E2=80=99s SIGHUP behavior for cert=
ificate
> >    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=3D# show ssl_key_file;
>  ssl_key_file
> --------------
>  server.key
> (1 row)
>
> test=3D# \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=3D# 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
>

--000000000000107c5d064d20bcf1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Tatsuo,<div><br></div><div>Have there been any further =
considerations regarding changes to the pgPool codebase to support SSL cert=
ificate rotation on reload?<br><br>As DigiCert has announced last year (<a =
href=3D"https://www.digicert.com/blog/tls-certificate-lifetimes-will-offici=
ally-reduce-to-47-days">https://www.digicert.com/blog/tls-certificate-lifet=
imes-will-officially-reduce-to-47-days</a>), 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 t=
o fully restart the service for certificate renewal increasingly impractica=
l.<br><br>Please let us know whether this enhancement is being considered, =
or if there are any plans or timelines for addressing it.</div><div><br></d=
iv><div>Regards,</div><div>Bob</div></div><br><div class=3D"gmail_quote gma=
il_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Oct 24, 2=
025 at 6:44=E2=80=AFAM Tatsuo Ishii &lt;<a href=3D"mailto:ishii@postgresql.=
org">ishii@postgresql.org</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">&gt; Hello,<br>
&gt; <br>
&gt; Please consider adding support for rotating SSL certificates on reload=
ing<br>
&gt; pgpool2 (i.e., sending SIGHUP to the pgpool parent), so that certifica=
te<br>
&gt; rotations do not require a full service restart. PostgreSQL can pick u=
p new<br>
&gt; certificates on reload/SIGHUP; pgpool currently requires a restart, wh=
ich<br>
&gt; causes connection disruptions.<br>
&gt; <br>
&gt; *Current behavior:*<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 - Replace certificate/key files used by pgpool (e.g., ser=
ver.crt,<br>
&gt;=C2=A0 =C2=A0 server.key, related CA chain).<br>
&gt;=C2=A0 =C2=A0 - Run systemctl reload pgpool2 (send SIGHUP to the pgpool=
 parent).<br>
&gt;=C2=A0 =C2=A0 - Observations: Existing and new client connections conti=
nue to present<br>
&gt;=C2=A0 =C2=A0 the old certificate. Only systemctl restart pgpool2 appli=
es the new certs<br>
&gt;=C2=A0 =C2=A0 (causing connection interruptions).<br>
<br>
Yes, that&#39;s the current behavior as described in the docs.<br>
<br>
&gt; *Expected behavior:*<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 - After systemctl reload pgpool2 / SIGHUP, pgpool should =
re-read<br>
&gt;=C2=A0 =C2=A0 SSL-related configuration (server cert, private key, chai=
n/CA, CRL if<br>
&gt;=C2=A0 =C2=A0 configured) and use them for new client connections, with=
out requiring a<br>
&gt;=C2=A0 =C2=A0 full restart.<br>
<br>
Doable but needs major surgery to the SSL subsystem<br>
(src/utils/pool_ssl.c) as it assumes that SSL configurations are never<br>
changed until restarting.<br>
<br>
&gt;=C2=A0 =C2=A0 - Existing connections can continue with the old context;=
 only new<br>
&gt;=C2=A0 =C2=A0 handshakes should use the updated materials.<br>
<br>
Probably doable.<br>
<br>
&gt;=C2=A0 =C2=A0 - If reload fails, log a clear error and keep using the p=
revious context<br>
&gt;=C2=A0 =C2=A0 to avoid breaking clients.<br>
&gt;=C2=A0 =C2=A0 - Consider parity with PostgreSQL=E2=80=99s SIGHUP behavi=
or for certificate<br>
&gt;=C2=A0 =C2=A0 reloads where feasible.<br>
<br>
Not sure if it&#39;s doable. Needs more research on current code.<br>
<br>
BTW, PostgreSQL behaves interestingly.<br>
<br>
# &quot;server.key&quot; is the correct ssl_key_file.<br>
<br>
test=3D# show ssl_key_file;<br>
=C2=A0ssl_key_file <br>
--------------<br>
=C2=A0server.key<br>
(1 row)<br>
<br>
test=3D# \q<br>
t-ishii$ psql -p 11002 -h localhost test<br>
psql (18.0)<br>
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compress=
ion: off, ALPN: postgresql)<br>
Type &quot;help&quot; for help.<br>
<br>
# Change ssl_key_file to &quot;server.key1&quot; which does not exists.<br>
# and reload<br>
<br>
t-ishii$ pg_ctl -D data0 reload<br>
server signaled<br>
<br>
# keep on using SSL connection<br>
<br>
t-ishii$ psql -p 11002 -h localhost test<br>
psql (18.0)<br>
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compress=
ion: off, ALPN: postgresql)<br>
Type &quot;help&quot; for help.<br>
<br>
# It seems PostgreSQL keep on using th previous ssl_key_file value,<br>
# but it shows the new ssl_key_file value.<br>
<br>
test=3D# show ssl_key_file;<br>
=C2=A0ssl_key_file <br>
--------------<br>
=C2=A0server.key1<br>
(1 row)<br>
<br>
Best regards,<br>
--<br>
Tatsuo Ishii<br>
SRA OSS K.K.<br>
English: <a href=3D"http://www.sraoss.co.jp/index_en/" rel=3D"noreferrer" t=
arget=3D"_blank">http://www.sraoss.co.jp/index_en/</a><br>
Japanese:<a href=3D"http://www.sraoss.co.jp" rel=3D"noreferrer" target=3D"_=
blank">http://www.sraoss.co.jp</a><br>
</blockquote></div>

--000000000000107c5d064d20bcf1--