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

Поиск
Список
Период
Сортировка
От Thomas Spear
Тема Re: TLS certificate alternate trust paths issue in libpq - certificate chain validation failing
Дата
Msg-id CAEAsNvS7+EAqPRtd09QmT6+RVZ7tCWYnJ3rbFcUuAPH9uxT_qQ@mail.gmail.com
обсуждение исходный текст
Ответ на TLS certificate alternate trust paths issue in libpq - certificate chain validation failing  (Thomas Spear <speeddymon@gmail.com>)
Ответы Re: TLS certificate alternate trust paths issue in libpq - certificate chain validation failing
Список 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 по дате отправления:

Предыдущее
От: "Anton A. Melnikov"
Дата:
Сообщение: Re: Refactoring backend fork+exec code
Следующее
От: Jacob Champion
Дата:
Сообщение: Re: TLS certificate alternate trust paths issue in libpq - certificate chain validation failing