TLS certificate alternate trust paths issue in libpq - certificate chain validation failing - Mailing list pgsql-hackers

From Thomas Spear
Subject TLS certificate alternate trust paths issue in libpq - certificate chain validation failing
Date
Msg-id CAEAsNvRuTWANc_OrECTD8bPHp9UdzNX6phgCYH5a1K7HExbwDQ@mail.gmail.com
Whole thread Raw
Responses Re: TLS certificate alternate trust paths issue in libpq - certificate chain validation failing
List pgsql-hackers
Hello, I've recently joined the list on a tip from one of the maintainers of jdbc-postgres as I wanted to discuss an issue we've run into and find out if the fix we've worked out is the right thing to do, or if there is actually a bug that needs to be fixed.

The full details can be found at github.com/pgjdbc/pgjdbc/discussions/3236 - in summary, both jdbc-postgres and the psql cli seem to be affected by an issue validating the certificate chain up to a publicly trusted root certificate that has cross-signed an intermediate certificate coming from a Postgres server in Azure, when using sslmode=verify-full and trying to rely on the default path for sslrootcert.

The workaround we came up with is to add the original root cert, not the root that cross-signed the intermediate, to root.crt, in order to avoid needing to specify sslrootcert=<the default path>. This allows the full chain to be verified.

I believe that either one should be able to be placed there without me needing to explicitly specify sslrootcert=<the default path>, but if I use the CA that cross-signed the intermediate cert, and don't specify sslrootcert=<some path, either default or not> the chain validation fails.

Thank you,

Thomas

pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: pg_parse_json() should not leak token copies on failure
Next
From: Jacob Champion
Date:
Subject: Re: TLS certificate alternate trust paths issue in libpq - certificate chain validation failing