When establishing a connection to a PostgreSQL server using a connection string, there are two parameters that can be provided to specify where to connect to: "host" and "hostaddr". If both are provided, the documentation states that "hostaddr" is used to actually establish the socket (thus avoiding a potentially-expensive DNS lookup), while "host" is used for doing some Kerberos stuff. It makes sense that in the case of an SSL connection with "sslmode=verify-full" (check that the server's certificate is signed by a trusted CA and has the correct hostname), if both parameters are provided, that "host" also be used for certificate checking. Unfortunately, as per line 536 of the file fe-secure.c in the PostgreSQL sources, if hostaddr is specified, SSL full verification just plain fails without trying at all. I suspect this line should be "if (!conn->pghost)" instead of "if (conn->pghostaddr)". There is no security vulnerability here, since "host" is a configuration slot intended to hold some kind of semantic name for the host as understood by the user (which is precisely what you want to verify a certificate against—that you are connecting to the semantically-correct server, not simply the one that happens to have the right IP address), while "hostaddr" is merely a network-level implementation detail which should be essentially meaningless to the user. Although it's easy enough to avoid the issue when using psql (just don't include "hostaddr" at all), this unfortunately causes all connections to fail when using pgAdmin3, as that program apparently does its own DNS lookups and always attaches a hostaddr (thus causing the confusing message "verified SSL connections are only supported when connecting to a host name" even if one *does* in fact specify a host*name* in the appropriate place!) Reproducible: Always Steps to Reproduce:
Not really sure what to do here. Bug poster: Is there an upstream discussion concerning this?
This is really a bug for upstream. We can do a patch here, but that'd only help us. Christopher, submit the above to pgsql-bugs or pgsql-hackers at postgresql.org.
Upstreamed with the bugs Web form as reference 5559. Will report back.
According to upstream this has been chalked up to documentation requiring clarification. Also, rereading the original comment, it appears that it is pgAdminIII that isn't behaving appropriately and should have been reported to them instead. (But, bonus for PgSQL upstream refining the docs.)
Looks like this has been fixed in 8.4.6 (upstream) and also 9.0.3 (Gentoo stable).
