Re: Proposal: Supporting URI SAN in Certificate Authentication

On Wed, Aug 26, 2026 at 11:07 AM Florin Irion <irionr(at)gmail(dot)com> wrote:
> > * How should multiple URI SAN entries be handled (first match, require uniqueness, mapping rules, etc.)?
>
> The key thing is that the client must tell PostgreSQL which user they want to connect as. Then PostgreSQL looks through all the mappings it found and checks if any of the SANs map to that requested user. If exactly one SAN matches the user, we allow the connection. If none match, we reject. If many SANs map to different users but the client already said which one they want, that is fine, we just use the right one.

I interpreted the question about "first match" to mean: what if many
SANs in the cert map to the *same* database user?

(IMO an implementation of this that ignored pg_ident mapping would be
vetoable without a really, _really_ good reason, so I'm not sure that
branch of the discussion needs to consume much energy.)

> I think this is better than trying to pick the first match automatically, because that can be confusing.

I don't understand what you mean here, in the context of our startup
handshake. We don't allow you to omit the database username from the
startup packet, so there couldn't be any guesswork around which DB
role a client meant to connect under.

> The pg_ident.conf rules let you organize this however makes sense for your setup.

Sort of. We're currently pretty bad at allowing you to say "or" in the
HBA. So without more design work, I don't think there's going to be a
way to dynamically switch the `clientname` setting from CN to DN to
URI (to email, to other SAN...); you'd have to choose one and stick to
it for a given HBA line.

--Jacob