Thread: Certificate validity error download.postgresql.org

--------------------------------
This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail.

> On 14 Oct 2021, at 14:34, Cedric Rey <cerey@groupemutuel.ch> wrote:

>  the certificate on download.postgresql.org has expired :

Are you perhaps running an old version of OpenSSL?

--
Daniel Gustafsson        https://vmware.com/

## Cedric Rey (cerey@groupemutuel.ch):

> the certificate on download.postgresql.org has expired :
> 
> openssl s_client -connect download.postgresql.org:443
> CONNECTED(00000003)
> depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
> verify error:num=10:certificate has expired
> notAfter=Sep 30 14:01:15 2021 GMT

That's complaining about the "DST Root CA X3" certificate, and that's
(partially) expected: https://letsencrypt.org/2021/10/01/cert-chaining-help.html

But the fact that you're seeing this indicates that you're either
running an horribly outdated version of openssl (as Daniel mentioned),
but even CentOS' "OpenSSL 1.0.2k-fips  26 Jan 2017" has been fixed
in this regard.
The other possibility is that your trusted CA list is outdated: that
would be package ca-certificates (same name in deb and rpm world).
I do know from my own experience that at least the "old" (2020.2.something)
Redhat package is missing the new "ISRG Root X1" certificate, you'll
need version 2021.2.something.

Regards,
Christoph

-- 
Spare Space

Hi, 

 It was indeed related to the ca-certificates package.

Thanks for your help!

Best Regards

-----Message d'origine-----
De : Christoph Moench-Tegeder [mailto:cmt@burggraben.net] 
Envoyé : jeudi 14 octobre 2021 15:29
À : Cedric Rey <cerey@groupemutuel.ch>
Cc : pgsql-general@lists.postgresql.org
Objet : Re: Certificate validity error download.postgresql.org

## Cedric Rey (cerey@groupemutuel.ch):

> the certificate on download.postgresql.org has expired :
> 
> openssl s_client -connect download.postgresql.org:443
> CONNECTED(00000003)
> depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3 verify 
> error:num=10:certificate has expired notAfter=Sep 30 14:01:15 2021 GMT

That's complaining about the "DST Root CA X3" certificate, and that's
(partially) expected: https://letsencrypt.org/2021/10/01/cert-chaining-help.html

But the fact that you're seeing this indicates that you're either running an horribly outdated version of openssl (as
Danielmentioned), but even CentOS' "OpenSSL 1.0.2k-fips  26 Jan 2017" has been fixed in this regard.
 
The other possibility is that your trusted CA list is outdated: that would be package ca-certificates (same name in deb
andrpm world).
 
I do know from my own experience that at least the "old" (2020.2.something) Redhat package is missing the new "ISRG
RootX1" certificate, you'll need version 2021.2.something.
 

Regards,
Christoph

--
Spare Space
-
https://www.groupemutuel.ch
https://www.facebook.com/groupemutuel.ch
https://twitter.com/Groupe_Mutuel
https://www.linkedin.com/company/groupe-mutuel
https://www.instagram.com/groupemutuel/
--------------------------------
This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and
deletethis e-mail.
 
Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Christoph Moench-Tegeder <cmt@burggraben.net> writes:
> I do know from my own experience that at least the "old" (2020.2.something)
> Redhat package is missing the new "ISRG Root X1" certificate, you'll
> need version 2021.2.something.

Seems unlikely that it changed that recently, for a couple of reasons:

* AFAICT, Red Hat's policy is to track the Mozilla NSS trusted-CA
list exactly.  They do update from there only once a year or so,
but NSS has trusted ISRG Root X1 for five years.

* Looking at "rpm -q ca-certificates --changelog" on a RHEL8 machine,
the package maintainer appears to have started a policy in mid-2019
of listing every single cert addition and removal in the changelog.
None of the updates since then mention ISRG Root X1.

* While Let's Encrypt's list of compatible platforms [1] doesn't mention
Red Hat directly, they do say that NSS has trusted X1 since release 3.26.
According to the changelog, Red Hat adopted that in August 2016:

    * Tue Aug 16 2016 Kai Engert <kaie@redhat.com> - 2016.2.9-3
    - Revert to the unmodified upstream CA list, changing the legacy trust
      to an empty list. Keeping the ca-legacy tool and existing config,
      however, the configuration has no effect after this change.

    * Tue Aug 16 2016 Kai Engert <kaie@redhat.com> - 2016.2.9-2
    - Update to CKBI 2.9 from NSS 3.26 with legacy modifications

So it sure looks from here like Red Hat has trusted the X1 certificate
since mid-2016, pretty much the same length of time as other major
distros.  The most probable explanation for the OP's problem seems
to be failure to update ca-certificates and/or openssl at all for
several years.

            regards, tom lane

[1] https://letsencrypt.org/docs/certificate-compatibility/

rpm -q ca-certificates --changelog
* Tue Sep 14 2021 Bob Relyea <rrelyea@redhat.com> - 2021.2.50-72
- Fix expired certificate.
-    Removing:
-     # Certificate "DST Root CA X3"


As you can see they just remove the old "DST Root CA X3" in the latest el7 ca-certificate version  which correct the
problemI had before. 

Openssl v1.0.2 is still the default version for Red Hat 7 and is already in the latest version available.

So no, it wasn't a failure to update ca-certificates for "several years" but for several days since the latest
ca-certificatesrpm was release Sep 14 2021. 

Anyway thanks for pointing me out that it was an error related to this expired Root CA and not related to postgresql
downloadsite certificate. 

Regards,

Cédric

-----Message d'origine-----
De : Tom Lane [mailto:tgl@sss.pgh.pa.us]
Envoyé : jeudi 14 octobre 2021 16:51
À : Christoph Moench-Tegeder <cmt@burggraben.net>
Cc : Cedric Rey <cerey@groupemutuel.ch>; pgsql-general@lists.postgresql.org
Objet : Re: Certificate validity error download.postgresql.org

Christoph Moench-Tegeder <cmt@burggraben.net> writes:
> I do know from my own experience that at least the "old"
> (2020.2.something) Redhat package is missing the new "ISRG Root X1"
> certificate, you'll need version 2021.2.something.

Seems unlikely that it changed that recently, for a couple of reasons:

* AFAICT, Red Hat's policy is to track the Mozilla NSS trusted-CA list exactly.  They do update from there only once a
yearor so, but NSS has trusted ISRG Root X1 for five years. 

* Looking at "rpm -q ca-certificates --changelog" on a RHEL8 machine, the package maintainer appears to have started a
policyin mid-2019 of listing every single cert addition and removal in the changelog. 
None of the updates since then mention ISRG Root X1.

* While Let's Encrypt's list of compatible platforms [1] doesn't mention Red Hat directly, they do say that NSS has
trustedX1 since release 3.26. 
According to the changelog, Red Hat adopted that in August 2016:

    * Tue Aug 16 2016 Kai Engert <kaie@redhat.com> - 2016.2.9-3
    - Revert to the unmodified upstream CA list, changing the legacy trust
      to an empty list. Keeping the ca-legacy tool and existing config,
      however, the configuration has no effect after this change.

    * Tue Aug 16 2016 Kai Engert <kaie@redhat.com> - 2016.2.9-2
    - Update to CKBI 2.9 from NSS 3.26 with legacy modifications

So it sure looks from here like Red Hat has trusted the X1 certificate since mid-2016, pretty much the same length of
timeas other major distros.  The most probable explanation for the OP's problem seems to be failure to update
ca-certificatesand/or openssl at all for several years. 

            regards, tom lane

[1] https://letsencrypt.org/docs/certificate-compatibility/
-
https://www.groupemutuel.ch
https://www.facebook.com/groupemutuel.ch
https://twitter.com/Groupe_Mutuel
https://www.linkedin.com/company/groupe-mutuel
https://www.instagram.com/groupemutuel/
--------------------------------
This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and
deletethis e-mail. 
Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Cedric Rey <cerey@groupemutuel.ch> writes:
> rpm -q ca-certificates --changelog
> * Tue Sep 14 2021 Bob Relyea <rrelyea@redhat.com> - 2021.2.50-72
> - Fix expired certificate.
> -    Removing:
> -     # Certificate "DST Root CA X3"

> As you can see they just remove the old "DST Root CA X3" in the latest el7 ca-certificate version  which correct the
problemI had before. 

Wow, that is quite interesting, because they've propagated no such
update to my RHEL8 or Fedora 34 machines (mumble dnf update mumble
... nope, still not there).  I speculate that that's because those
releases don't need it: they're both running openssl 1.1.1something,
which will do the right thing as soon as it finds the ISRG Root X1
certificate in the chain.  But RHEL7 is still using openssl 1.0.2,
which will follow the chain to the DST cert and then spit up [1].
So evidently Red Hat has implemented OpenSSL's "workaround 1" [2]
on RHEL7, but they left well enough alone on newer platforms.

They could not have pushed out the DST cert removal much before
that cert expired, for fear of causing unnecessary problems
elsewhere.  So that's why the seemingly short notice.

            regards, tom lane

[1] https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816
[2] https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/