MIME-Version: 1.0
References: <20260319.192225.349123033503761335.ishii@postgresql.org>
 <CAHtZvrdud7gjX9pq7ayU2VBQkCosZ7qcx6L9r-KbQkqKW_D9eQ@mail.gmail.com>
 <20260326.170716.601660341897872041.ishii@postgresql.org>
 <20260326.191902.1769703442358463290.ishii@postgresql.org>
In-Reply-To: <20260326.191902.1769703442358463290.ishii@postgresql.org>
From: Bob Ross <bob.ross.19821@gmail.com>
Date: Fri, 27 Mar 2026 19:16:12 +0100
Message-ID: 
 <CAHtZvrfap1R6+D=KsfE1iPU6_reGaPyf=m_GryEUNrNWe0KYbg@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="000000000000a8824d064e057f7f"
Archived-At: 
 <https://www.postgresql.org/message-id/CAHtZvrfap1R6%2BD%3DKsfE1iPU6_reGaPyf%3Dm_GryEUNrNWe0KYbg%40mail.gmail.com>
Precedence: bulk

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

Hi Tatsuo,

I believe no additional changes are needed for healthcheck and streaming
replication check.

My patch focuses on the frontend-accept path, where SSL_ServerSide_init()
maintains a process-wide cached SSL_frontend_context reused across incoming
TLS handshakes, and therefore must be explicitly refreshed on reload.

In contrast, the health check (src/main/health_check.c) and the SR check
worker (src/streaming_replication/pool_worker_child.c) establish outgoing
connections to PostgreSQL backends via pool_ssl_negotiate_clientserver().
This invokes init_ssl_ctx() for each new connection, creating a fresh
SSL_CTX and reading SSL-related settings (ssl_cert, ssl_key, ssl_ca_cert,
etc.) directly from pool_config at connection time. There is no long-lived
SSL context to refresh in these processes.

Given that the SSL configuration parameters are now marked as CFGCXT_RELOAD
in src/config/pool_config_variables.c, a SIGHUP causes both processes to
reload pool_config via their respective reload_config() functions. As a
result, subsequent outgoing backend connections will naturally pick up the
updated certificate settings.

Please let me know what you think.

Best regards,
Bob


On Thu, Mar 26, 2026 at 11:19=E2=80=AFAM Tatsuo Ishii <ishii@postgresql.org=
> wrote:

> Hi Bob,
>
> > Thank you for the patch! I will look into the patch.
>
> I skimmed through the patch. You changed main.c and child.c to call
> SSL_ServerSide_init() so that they reload new SSL parameters. However,
> in Pgpool-II there are two more places which could use SSL connection
> to PostgreSQL server: health check and streaming replication check. I
> suspect they need to call SSL_ServerSide_init() while reloading the
> config file. What do you think?
>
> Regards,
> --
> Tatsuo Ishii
> SRA OSS K.K.
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.sraoss.co.jp
>

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

<div dir=3D"ltr"><div>Hi Tatsuo,<br><br>I believe no additional changes are=
 needed for healthcheck and streaming replication check.<br><br>My patch fo=
cuses on the frontend-accept path, where SSL_ServerSide_init() maintains a =
process-wide cached SSL_frontend_context reused across incoming TLS handsha=
kes, and therefore must be explicitly refreshed on reload.<br><br>In contra=
st, the health check (src/main/health_check.c) and the SR check worker (src=
/streaming_replication/pool_worker_child.c) establish outgoing connections =
to PostgreSQL backends via pool_ssl_negotiate_clientserver(). This invokes =
init_ssl_ctx() for each new connection, creating a fresh SSL_CTX and readin=
g SSL-related settings (ssl_cert, ssl_key, ssl_ca_cert, etc.) directly from=
 pool_config at connection time. There is no long-lived SSL context to refr=
esh in these processes.<br><br>Given that the SSL configuration parameters =
are now marked as CFGCXT_RELOAD in src/config/pool_config_variables.c, a SI=
GHUP causes both processes to reload pool_config via their respective reloa=
d_config() functions. As a result, subsequent outgoing backend connections =
will naturally pick up the updated certificate settings.<br><br>Please let =
me know what you think.<br><br>Best regards,<br>Bob</div><div><br></div><di=
v><br></div></div><br><div class=3D"gmail_quote gmail_quote_container"><div=
 dir=3D"ltr" class=3D"gmail_attr">On Thu, Mar 26, 2026 at 11:19=E2=80=AFAM =
Tatsuo Ishii &lt;<a href=3D"mailto:ishii@postgresql.org">ishii@postgresql.o=
rg</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
">Hi Bob,<br>
<br>
&gt; Thank you for the patch! I will look into the patch.<br>
<br>
I skimmed through the patch. You changed main.c and child.c to call<br>
SSL_ServerSide_init() so that they reload new SSL parameters. However,<br>
in Pgpool-II there are two more places which could use SSL connection<br>
to PostgreSQL server: health check and streaming replication check. I<br>
suspect they need to call SSL_ServerSide_init() while reloading the<br>
config file. What do you think?<br>
<br>
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>

--000000000000a8824d064e057f7f--