Thank you for your feedback. You are right, libpq verify if the server is trustworthy by checking server certificate and check hostname matches with server common name when sslmode is verify-full, and it is already explained in another documentation page https://www.postgresql.org/docs/current/libpq-ssl.html
Having done another investigation, I found that the original documentation (https://www.postgresql.org/docs/current/auth-cert.html) is actually right. The server is indeed also checking the client certificate cn matches the database user name if the authentication method is set to "cert"
Please disregard this patch.
thanks!
Cary
---- On Mon, 02 Mar 2020 19:23:37 -0800 Chris Bandy <bandy.chris@gmail.com> wrote ----
Hi, Cary.
On 3/2/20 1:06 PM, Cary Huang wrote: > Hi > > I found a document bug about client authentication using TLS > certificate. When clientcert authentication is enabled in pg_hba.conf, > libpq does not verify that the *common name*in certificate > matches*database username*like it is described in the documentation > before allowing client connection. > > Instead, when sslmode is set to “verify-full”, libpq will verify if the > *server host name*matches the *common name *in client certificate.
This sounds incorrect. My understanding is that the *server* host name is always matched with the *server* common name.
When > sslmode is set to “verify-ca”, libpq will verify that the client is > trustworthy by checking the certificate trust chain up to the root > certificate and it does not verify *server hostname*and > certificate*common name *match in this case.
Similarly, libpq will verify the *server* is trustworthy by checking the *server* certificate up to the root. It does not verify that the host name matches the common name in the *server* certificate.
In all cases, libpq is responsible for verifying the *server* is who it claims to be.