Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sKtn1-00CYKj-2C for pgsql-general@arkaria.postgresql.org; Sat, 22 Jun 2024 05:59:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sKtmx-0018sp-W1 for pgsql-general@arkaria.postgresql.org; Sat, 22 Jun 2024 05:59:52 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sKhwy-005zap-9s for pgsql-general@lists.postgresql.org; Fri, 21 Jun 2024 17:21:24 +0000 Received: from mail-lj1-x231.google.com ([2a00:1450:4864:20::231]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sKhwv-002rQ1-PZ for pgsql-general@postgresql.org; Fri, 21 Jun 2024 17:21:24 +0000 Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-2ec4eefbaf1so8711991fa.1 for ; Fri, 21 Jun 2024 10:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718990479; x=1719595279; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cM80OKymSCWO4RYcmxqyNZ/cIJ25Enq0nZVTfOS432A=; b=eHt0bjsglwY/M+hJoXcDNF7XxXFU7ac9tleCLiGRXOs3AvEXKm7qAEjLmokPaJsYwT ghMRWHgnAMmqV+55u9qC0tej9PnMv46Yj3dBFLtfl2M+/1bJaQoMJmirP7eUzsmXG1e9 EY6LrEJRSr8EhCHxsMh42654S40jS4DVIQNer41vsxOrft5ZvUjOBmw679vnbWBpm+zw mgHoYAOBON5qkFzkWSbi17O/MpEIKf+Mzc2EbTLEm8NbR7Yd4L6uTE1fxtWhXxfGujU9 GfsRsEeVd2pqqddNy5N+X7tc1xMM8l6N1njHGaP0Mty1m6bc+trr4frn+S/1wHj6YUUq Am6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718990479; x=1719595279; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cM80OKymSCWO4RYcmxqyNZ/cIJ25Enq0nZVTfOS432A=; b=LlwcFOjOKcV+Y3CE+JAr5ijNX8Mc8vmPU2wqKTF+kqEJ+hS9le1LR+F0wqFc6+MKjm PBcM7kTR786UKP4/5qN7BfSh3tCQH7cAeREys77mta2czYePoibWikEawN/tZXsWDjih uWxBAR1qVHIpAR2l7red8EdGdup2VQnznTEj/BsomeGqpvH/BjvqEzrUrmpyw0+Tlcn8 cY7MoHCzVgYkb/Gj/hSeDbTD3xT386QVhV1o3h/oicLnJsRnV60IHWRQ2ujVnA8ObYbD cFALXMUld3TcHYsG9Js2gbdvCfQT8T7od8rWpKv1USVLgTuzBGx6/FC43SlGDM0DDi1G HPyQ== X-Gm-Message-State: AOJu0YwThfHbZc+DqEyL/IqJrd05b+Hh9uI6zFPIz3SqZE8O9ION2F7E 0d85ea6xy23ifUl5ENAOakK3N4mZUgMv7Ti9SwrqmuSAR6aPMCZGuEDpi+pA5w2lGzD9dNKEcg0 YitPX7K+/RBXka93wwMSmfHAA9zqNpg== X-Google-Smtp-Source: AGHT+IEs3Zq8fv4EO9iw5eSe3fVco3/6te3deaeAvYuVtwXvTxz+mHHT0EYI/Ib1RtH5sGkjjDz38fQYG23A1rPWFEw= X-Received: by 2002:a2e:9088:0:b0:2ec:1dfc:45bf with SMTP id 38308e7fff4ca-2ec3cfd6ea5mr45010621fa.42.1718990479276; Fri, 21 Jun 2024 10:21:19 -0700 (PDT) MIME-Version: 1.0 References: <603291.1718988382@sss.pgh.pa.us> In-Reply-To: <603291.1718988382@sss.pgh.pa.us> From: Drew Zoellner Date: Fri, 21 Jun 2024 12:21:07 -0500 Message-ID: Subject: Re: Replication using mTLS issue To: Tom Lane Cc: pgsql-general@postgresql.org, postgres@thewickedtribe.net Content-Type: multipart/alternative; boundary="000000000000e3c656061b69a869" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000e3c656061b69a869 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tom, thanks for the response! So the same user is able to connect using a non replication connection using the same mtls certificate and pg_ident.conf map. So it seems like the cert & map are working for this user. hostssl all pgrepmgr_nonprod 100.0.0.0/8 cert map=3Dpgrepmgr_nonprod_map This above seems to be the rule that matched the non replication connection which was successful. I have tried relaxing the pg_hba.conf line to all like you suggested for the username and also for IPs and other combinations, unfortunately nothing was working. I have been sure to use SELECT pg_reload_conf(); to update changes made to the pg_hba.conf. I have additionally used SELECT pg_hba_file_rules(); to verify the rules are showing up as expected from the live DB perspective. Since non replication connections are working, and the only change to HBA conf for the replication connection is just all -> replication , it seems like it should be matching. Any other suggestions? Thanks, Drew. On Fri, Jun 21, 2024 at 11:46=E2=80=AFAM Tom Lane wrote= : > Drew Zoellner writes: > > Hi Postgres team, I=E2=80=99m receiving an issue matching pg_hba rules = that I > can=E2=80=99t > > seem to sort out. I am trying to use mtls certificate authentication fo= r > > physical replication connections but keep receiving the following error= =E2=80=A6 > > > pg_receivewal: error: FATAL: no pg_hba.conf entry for replication > > connection from host "100.84.12.223", user "pgrepmgr_nonprod", SSL on > > > My pg_hba.conf file contains > > hostssl replication pgrepmgr_nonprod 100.0.0.0/8 cert > map=3Dpgrepmgr_nonprod_map > > Hm, the match failure must be on user name. What certificate are you > using on the client side, and what user name does pgrepmgr_nonprod_map > map it to? Does it succeed if you weaken the hba entry to > > hostssl replication all 100.0.0.0/8 cert map=3Dpgrepmgr_nonprod_m= ap > > > Is cert authentication supported for replication connections? > > Should be. But you might find it easier to debug the auth failure > in a non-replication context, ie add > > hostssl all pgrepmgr_nonprod 100.0.0.0/8 cert > map=3Dpgrepmgr_nonprod_map > > and then see if you can connect with the same credentials from psql > or your favorite other client. > > BTW, don't forget you have to signal the postmaster to reload > configuration after any change in these files. > > regards, tom lane > --000000000000e3c656061b69a869 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom, thanks for the response!
<= br>
So the same user is able to connect using a non = replication connection using the same mtls certificate and pg_ident.conf ma= p. So it seems like the cert & map are working for this user.

hostssl all pgrepmgr_nonprod 100.0.0.0/8 cert map=3Dpgrepmgr_nonprod_map<= /div>

This above seems to be t= he rule that matched the non replication connection which was successful.= =C2=A0

I have tried rela= xing the pg_hba.conf line to all like you suggested for the username and al= so for IPs and other combinations, unfortunately nothing was working.=C2=A0=

I have been sure to use= SELECT pg_reload_conf(); to update changes made to the pg_hba.conf. I have= additionally used SELECT pg_hba_file_rules(); to verify the rules are show= ing up as expected from the live DB perspective.
Since non replication connections are working, and= the only change to HBA conf for the replication connection is just all -&g= t; replication , it seems like it should be matching. Any other suggestions= ?

Thanks, Drew.

On F= ri, Jun 21, 2024 at 11:46=E2=80=AFAM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Drew= Zoellner <= drewtzoellner@gmail.com> writes:
> Hi Postgres team, I=E2=80=99m receiving an issue matching pg_hba rules= that I can=E2=80=99t
> seem to sort out. I am trying to use mtls certificate authentication f= or
> physical replication connections but keep receiving the following erro= r=E2=80=A6

> pg_receivewal: error: FATAL:=C2=A0 no pg_hba.conf entry for replicatio= n
> connection from host "100.84.12.223", user "pgrepmgr_no= nprod", SSL on

> My pg_hba.conf file contains
>=C2=A0 =C2=A0 =C2=A0 =C2=A0hostssl replication pgrepmgr_nonprod 100.0.0.0/8 cert map=3Dpgrepmgr_nonprod_map

Hm, the match failure must be on user name.=C2=A0 What certificate are you<= br> using on the client side, and what user name does pgrepmgr_nonprod_map
map it to?=C2=A0 Does it succeed if you weaken the hba entry to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 hostssl replication all
100.0.0.0/8 cert map=3Dpgr= epmgr_nonprod_map

> Is cert authentication supported for replication connections?

Should be.=C2=A0 But you might find it easier to debug the auth failure
in a non-replication context, ie add

=C2=A0 =C2=A0 =C2=A0 =C2=A0 hostssl all pgrepmgr_nonprod 100.0.0.0/8 cert map= =3Dpgrepmgr_nonprod_map

and then see if you can connect with the same credentials from psql
or your favorite other client.

BTW, don't forget you have to signal the postmaster to reload
configuration after any change in these files.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 regards, tom lane
--000000000000e3c656061b69a869--