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.
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?
- 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?
The patchset roadmap:
- 0001 moves inet_net_pton() to src/port, since libpq will need it.
- 0002 implements the new functionality and adds tests.
WDYT?
Thanks,
--Jacob
