Date: Thu, 9 Sep 2021 16:57:08 +0000
From: Stefan Huehner <stefan@huehner.org>
To: Christoph Berg <myon@debian.org>, pgsql-pkg-debian@postgresql.org,
	sysadmins <sysadmins@lists.postgresql.org>
Subject: Re: apt.postgresql.org repo via https will fail will some users
 starting 2021-10-01
Message-ID: <20210909165708.GG6114@huehner.biz>
References: <20210908164806.GC6114@huehner.biz>
 <YTn/LRZEtVi38f5G@msg.df7cb.de>
 <20210909151508.GE6114@huehner.biz>
 <YTopX7uzJQUqGjum@msg.df7cb.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YTopX7uzJQUqGjum@msg.df7cb.de>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: 
 <https://www.postgresql.org/message-id/20210909165708.GG6114%40huehner.biz>
Precedence: bulk

On Thu, Sep 09, 2021 at 05:33:51PM +0200, Christoph Berg wrote:
> Re: Stefan Huehner
> > > > - Some on the website
> > > > - Think on reconfiguring certbot/Let's Encrypt on the server to switch to the alternative chain (avoiding this bug but breaking compatibility with old Android
> > > 
> > > That's probably rather the ca-certificates package?
> > 
> > Not in this case, i know a bit confusing.
> > That upstream article has more details:
> > https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816
> > Part: How to support older OpenSSL versions
> > 
> > In (not so) short: ca-certificates is fine to have trust anchor for Lets Encrypt.
> > However not everybody directly trust Let's Encrypt (missing entry in their equivalent of ca-certificates (i.e. old Android).
> > 
> > To keep those other clients supported they employed a bit of a trick which has an 'expired root certificates' in the chain from your server-cert to their root. At the same time there is 2nd valid path. But old version of software (openssl,gnutls) just stop + fail on seeing 'expired'.
> > 
> > Best they could do if offer server owner (certbot parameter when requesting ssl certificate to select):
> 
> Ah, I thought you meant the end-users servers running PostgreSQL when
> you said "server".
Sorry for the confusion.

But now thinking they could be affected (but special cases only)
- There may be a case for running PostgreSQL instances
- As this affects any 'client' using above older libraries
- libpq linked with old ssl, connecting via SSL to remote pg having Let's Encrypt and client validating certificate (verify-ca,verify-full) 
- or outgoing connections using fdw 

Note:
This is just me trying to construct a flow which might fail.
Again kind of 'info for supporting users' as bug is libssl we link against only.
Maybe also interesting to spread to the yum-side of things (Devrim?) to check thei rpm using packaging/distros.
But also not sure if that is common enough even to make a big topic out of...

> 
> For changing the webservers, we'd need to get pginfra on board, Cc'ed
> now.

For the sysadmins:
- 'changing' would avoid the bug described here + not for debian
  https://lists.debian.org/debian-lts/2021/09/msg00008.html
  for people running old distros (no fix, or not updated, ...)
- But it will break using the webserver with other clients (i.e. older android)
- Need to pick the 'smaller problem' based on the concrete site and its users/clients
- This is generic Let's Encrypt topic (not just apt.postgresql.org host)
- Above letsencrypt link has bigger explanation + all the background

Stefan