To resolve this confusion all we need is to add something like to
documentation
http://www.postgresql.org/docs/9.5/static/libpq-ssl.html
Currently PostgreSQL supports only Subject Alternative Name attribute(s)
of type dNSName, and IP type isn't supported.
and remove
If the connection is made using an IP address instead of a host name,
the IP address will be matched (without doing any DNS lookups).
The last one seems to be incorrect, if the SAN IP attributes are ignored.
Am I correct?
Sergei Agalakov
> On 09/05/16 20:08, sergei(dot)agalakov(at)getmyle(dot)com wrote:
> > CentOS 7, OpenSSL 1.0.2h, Postgres 9.5.2
> > 1. Created server certificate signed by local CA with three Subject
> > Alternative Name values
> > $ openssl x509 -in server.crt -text -noout
> > ...
> > X509v3 Subject Alternative Name:
> > DNS:myle-db001a-small.c.myle-gce-proj-01.internal, IP
> > Address:162.222.177.29, IP Address:10.240.0.3
> > ...
> > 2. Created and copied root.crt for local CA certificate
> > 3. Switched SSL mode to verify-full
> > $export PGSSLMODE=verify-full
> > 4. $psql -h 10.240.0.3 -U postgres
> > psql: server certificate for "myle-db001a-small.c.myle-gce-proj-01.internal"
> > does not match host name "10.240.0.3"
> > According to E.3.3.1.4. SSL in
> >http://www.postgresql.org/docs/9.5/static/release-9-5.html
> > PG 9.5 should check all Subject Alternative Names to match in the
> > certificate. The same implies in
> >http://www.postgresql.org/docs/9.5/static/libpq-ssl.html
> > "In verify-full mode, the host name is matched against the certificate's
> > Subject Alternative Name attribute(s), or against the Common Name attribute
> > if no Subject Alternative Name of type dNSName is present."
> > An expected result was a SSL connection because one of SAN attributes
> > matched host name. Instead a connection was refused.
>
> PostgreSQL only pays attention to "DNS" SAN attributes, the IP addresses
> are ignored. It would be a nice feature if it did, but that hasn't been
> implemented.
>
> - Heikki
>