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

From Thomas Spear
Subject Re: TLS certificate alternate trust paths issue in libpq - certificate chain validation failing
Date
Msg-id CAEAsNvS7+EAqPRtd09QmT6+RVZ7tCWYnJ3rbFcUuAPH9uxT_qQ@mail.gmail.com
Whole thread Raw
In response to TLS certificate alternate trust paths issue in libpq - certificate chain validation failing  (Thomas Spear <speeddymon@gmail.com>)
Responses Re: TLS certificate alternate trust paths issue in libpq - certificate chain validation failing
List pgsql-hackers
On Tue, Apr 30, 2024 at 5:19 PM Jacob Champion <jacob.champion@enterprisedb.com> wrote:
On Tue, Apr 30, 2024 at 2:41 PM Thomas Spear <speeddymon@gmail.com> wrote:
> 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.

Hopefully someone more familiar with the Azure cross-signing setup
sees something obvious and chimes in, but in the meantime there are a
couple things I can think to ask:

1. Are you sure that the server is actually putting the cross-signed
intermediate in the chain it's serving to the client?


Hello Jacob, thanks for your reply.

I can say I'm reasonably certain. I dumped out the certificates presented by the server using openssl, and the chain that gets output includes "Microsoft Azure RSA TLS Issuing CA 08".
On https://www.microsoft.com/pkiops/docs/repository.htm the page says that that cert was cross-signed by the DigiCert RSA G2 root.
The postgres server appears to send the Microsoft root certificate instead of the DigiCert one, which should be fine. The server sends the "Microsoft RSA Root Certificate Authority 2017" root.
As far as I understand, a server sending a root certificate along with the intermediate is a big no-no, but that's a topic for a different thread and audience most likely. :)

2. What version of OpenSSL? There used to be validation bugs with
alternate trust paths; hopefully you're not using any of those (I
think they're old as dirt), but it doesn't hurt to know.


The openssl version in my Windows test system is 3.0.7. It's running Almalinux 9 in WSL2, so openssl is from the package manager. The container image I'm using has an old-as-dirt openssl 1.1.1k. It's built using a RHEL UBI8 image as the base layer, so it doesn't surprise me that the package manager-provided version of openssl here is old as dirt, so I'll have to look at making a build of 3.x for this container or maybe switching out the base layer to ubuntu temporarily to test if we need to.
 
3. Can you provide a sample public certificate chain that should
validate and doesn't?


I'll get back to you on this one. I'll have to check one of our public cloud postgres instances to see if I can reproduce the issue there in order to get a chain that I can share because the system where I'm testing is a locked down jump host to our Azure GovCloud infrastructure, and I can't copy anything out from it.

Thanks again

--Thomas

pgsql-hackers by date:

Previous
From: "Anton A. Melnikov"
Date:
Subject: Re: Refactoring backend fork+exec code
Next
From: Jacob Champion
Date:
Subject: Re: TLS certificate alternate trust paths issue in libpq - certificate chain validation failing