On 12/15/21 20:13, Jacob Champion wrote:
> Hello all,
>
> libpq currently supports server certificates with a single IP address
> in the Common Name. It's fairly brittle; as far as I can tell, the
> single name you choose has to match the client's address exactly.
>
> Attached is a patch for libpq to support IP addresses in the server's
> Subject Alternative Names, which would allow admins to issue certs for
> multiple IP addresses, both IPv4 and IPv6, and mix them with
> alternative DNS hostnames. These addresses are compared bytewise
> instead of stringwise, so the client can contact the server via
> alternative spellings of the same IP address.
Good job, this is certainly going to be useful.
>
> This patch arose because I was writing tests for the NSS implementation
> that used a server cert with both DNS names and IP addresses, and then
> they failed when I ran those tests against the OpenSSL implementation.
> NSS supports this functionality natively. Anecdotally, I've heard from
> at least one client group who is utilizing IP-based certificates in
> their cloud deployments. It seems uncommon but still useful.
>
> There are two open questions I have; they're based on NSS
> implementation details that I did not port here:
>
> - NSS allows an IPv4 SAN to match an IPv6 mapping of that same address,
> and vice-versa. I chose not to implement that behavior, figuring it
> is easy enough for people to issue a certificate with both addresses.
> Is that okay?
Sure.
>
> - If a certificate contains only iPAddress SANs, and none of them
> match, I fall back to check the certificate Common Name. OpenSSL will
> not do this (its X509_check_ip considers only SANs). NSS will only do
> this if the client's address is itself a DNS name. The spec says that
> we can't fall back to Common Name if the SANs contain any DNS
> entries, but it's silent on the subject of IP addresses. What should
> the behavior be?
I don't think we should fall back on the CN. It would seem quite odd to
do so for IP addresses but not for DNS names.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com