Re: TLS certificate alternate trust paths issue in libpq - certificate chain validation failing

From: Thomas Spear <speeddymon(at)gmail(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: TLS certificate alternate trust paths issue in libpq - certificate chain validation failing
Date: 2024-05-01 13:48:06
Message-ID: CAEAsNvS7+EAqPRtd09QmT6+RVZ7tCWYnJ3rbFcUuAPH9uxT_qQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 30, 2024 at 5:19 PM Jacob Champion <
jacob(dot)champion(at)enterprisedb(dot)com> wrote:

On Tue, Apr 30, 2024 at 2:41 PM Thomas Spear <speeddymon(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2024-05-01 14:23:48 Re: TLS certificate alternate trust paths issue in libpq - certificate chain validation failing
Previous Message Anton A. Melnikov 2024-05-01 13:32:24 Re: Refactoring backend fork+exec code