On Thu, Sep 09, 2021 at 02:33:49PM +0200, Christoph Berg wrote:
> Re: Stefan Huehner
> > sending this here as looks like https://apt.postgresql.org is affected by this so this could trigger some
support/userquestions.
> >
> > Note this only (!) happens when using https:// in sources.list for the pgdg repo.
>
> Hi,
>
> thanks for sharing this.
>
> We aren't advertising https:// for apt.postgresql.org anywhere, but
> the download instructions tell users to "wget" the repository key from
> https://www.postgresql.org, so we are at least somewhat affected.
> (wget is using gnutls at least in unstable.)
>
> > Ideas:
> > - Do nothing apt.postgresql suggest http:// in the instructions
> > - Some on the website
> > - Think on reconfiguring certbot/Let's Encrypt on the server to switch to the alternative chain (avoiding this bug
butbreaking 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
chainfrom 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):
a.) Default chain (compatible still with old android) but triggering this bug
b.) Alternative chain (ignore old android) but keep compatible with old openssl/gnutls
That link goes into much more detail but hopefully now clearer.
That is also why i raised this here as a choice for apt.postgresql.org hosting (if you think it's a useful workaround)
>
> > - Raise as bug to debian also (against openssl/gnutls) to maybe patch both in stable also to avoid this ?
> > - Not sure if that is a interesting/acceptable material for stable/old-stable?
>
> If stretch/buster/bullseye are affected, these should be fixed, yes.
>
> Though none of this is material for the PostgreSQL packages, can you
> raise the issue with the LTS team?
Will raise there.
Hopefuly above also clarified why i sent that here (not about any PostgreSQL package, but apt.postgresql.org server
admintopic).
Stefan