[PATCH] Documentation bug related to client authentication using TLS certificate
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t42018psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 02:56 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t42018_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t42018_1 && git checkout t42018_1Patchset v1 (message #1) is on t42018_1
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. 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.
The attached patch corrects the clientcert authentication description in the documentation
cheers
Cary Huang
-------------
HighGo Software Inc. (Canada)
mailto:cary.huang@highgo.ca
Import Notes
Reply to msg id not found:
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.
-- Chris
Hi Chris
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.
-- Chris