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