Re: Proposal: Supporting URI SAN in Certificate Authentication

Il giorno ven 27 mar 2026 alle ore 14:21 olivier cano <
kindermoumoute(at)gmail(dot)com> ha scritto:

>
> * How should multiple URI SAN entries be handled (first match, require
> uniqueness, mapping rules, etc.)?
>
> Hello,

I think teh best approach is to keep it simple and explicit. When a
certificate has multiple URI SANs, PostgreSQL should extract all of them
and then try to map each one using the pg_ident.conf rules, same like we do
today with CN or DN.

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.

This way we are not guessing. The audit log will show exactly which SAN was
used, not just "some certificate matched". This is important for security
and for tracking what happened.

I think this is better than trying to pick the first match automatically,
because that can be confusing. Different systems might arrange the SANs in
different order, and then the same certfiicate behaves differently. With
explicit matching, everything is clear.

The certificate can still contain many SANs for different purposes - maybe
DNS names for Kubernetes, and URI names for database auth. The
pg_ident.conf rules let you organize this however makes sense for your
setup.

For example, if you have one certificate with three SANs and they all map
to different database users via your rules, the client just needs to say
which user they want, and then it works.

This follows the same logic that already exists with DN.

I will start looking into this approach and propose a patch, we can discuss
more while actually doing it.

Cheers,
Florin

--
* Florin Irion *
* https://www.enterprisedb.com <https://www.enterprisedb.com/>*