From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Drew Zoellner <drewtzoellner(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org, postgres(at)thewickedtribe(dot)net |
Subject: | Re: Replication using mTLS issue |
Date: | 2024-06-21 18:24:01 |
Message-ID: | 630189.1718994241@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Drew Zoellner <drewtzoellner(at)gmail(dot)com> writes:
> 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.
Hmph. I tried to reproduce your problem, and it works for me: I can
create a replication connection that's authenticated by certificate
and relies on a username map to map from the CN in the client
certificate to the database username that's mentioned in the "hostssl
replication" entry.
All I can suggest at this point is to go over your configuration
with a fine-tooth comb, looking for probably-silly mistakes such as
inconsistent spellings. One thing I can think of to mention in
particular is to be sure that the standby's primary_conninfo
explicitly includes "user=pgrepmgr_nonprod", as that's likely not the
user name it'd default to.
Another idea could be to enable log_connections on the primary,
and see if the incoming connection request looks different than
you were expecting.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Shenavai, Manuel | 2024-06-21 19:31:14 | RE: Autovacuum, dead tuples and bloat |
Previous Message | Drew Zoellner | 2024-06-21 17:21:07 | Re: Replication using mTLS issue |