Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mOM3r-0003BB-Tn for pgsql-pkg-debian@arkaria.postgresql.org; Thu, 09 Sep 2021 15:33:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mOM3q-0000QS-0O for pgsql-pkg-debian@arkaria.postgresql.org; Thu, 09 Sep 2021 15:33:58 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mOM3p-0000QJ-Rr for pgsql-pkg-debian@lists.postgresql.org; Thu, 09 Sep 2021 15:33:57 +0000 Received: from feynman.df7cb.de ([195.49.152.168]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mOM3m-0003I9-7L for pgsql-pkg-debian@postgresql.org; Thu, 09 Sep 2021 15:33:56 +0000 Received: from msg.df7cb.de (unknown [IPv6:2003:5b:203b:100:7627:eaff:fe52:8e03]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) by feynman.df7cb.de (Postfix) with ESMTPSA id 4H53274kyVz3Dwx; Thu, 9 Sep 2021 17:33:51 +0200 (CEST) Date: Thu, 9 Sep 2021 17:33:51 +0200 From: Christoph Berg To: Stefan Huehner Cc: pgsql-pkg-debian@postgresql.org, sysadmins Subject: Re: apt.postgresql.org repo via https will fail will some users starting 2021-10-01 Message-ID: Mail-Followup-To: Christoph Berg , Stefan Huehner , pgsql-pkg-debian@postgresql.org, sysadmins References: <20210908164806.GC6114@huehner.biz> <20210909151508.GE6114@huehner.biz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210909151508.GE6114@huehner.biz> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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". For changing the webservers, we'd need to get pginfra on board, Cc'ed now. Christoph