GNU bug report logs -
#50921
GNU ELPA TLS errors: server is returning chain with expired root
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#50921: GNU ELPA TLS errors: server is returning chain with expired root
which was filed against the emacs package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 50921 <at> debbugs.gnu.org.
--
50921: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=50921
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
> Date: Thu, 30 Sep 2021 20:24:28 +0000
> From: John Cummings <john <at> rootabega.net>
>
> I'm not sure if we are supposed to report infrastructure problems as Emacs bugs, but it should be easy to close if not. I, and at least a few others, have had TLS connection problems to GNU ELPA in the last day or two, with the errors:
>
> |Issued by: R3
> |Issued to: CN=elpa.gnu.org
> |Hostname: elpa.gnu.org
> |Public key: RSA, signature: RSA-SHA256
> |Protocol: TLS1.3, key: ECDHE-RSA, cipher: AES-256-GCM, mac: AEAD
> |Security level: Medium
> |Valid: From 2021-09-28 to 2021-12-27
> |
> |
> |The TLS connection to elpa.gnu.org:443 is insecure for the following
> |reasons:
> |
> |certificate has expired
> |certificate could not be verified
>
> It appears that elpa.gnu.org is returning a certificate chain referring to a root certificate that expired today. (More info: https://twitter.com/letsencrypt/status/1443621997288767491) I don't know if GnuTLS is supposed to be able to work around this (Firefox seems to, for instance), but I think it's a safe bet this is the cause of these connection errors.
It isn't our issue, it's a possible issue with gnu.org infrastructure
and "older" TLS libraries. The issue is known to GNU sysadmins and
they are working on it. However, what they advise is to upgrade your
TLS libraries. Here's a quote from what they told me:
[GNU machines] have a lets encrypt cert that is valid, it seems some
older tls libraries dont like that is has 2 alternate intermediate
certificates and one of them expired.
So this is not an Emacs problem, and I'm therefore closing this bug.
If you want to pursue this further, please write to sysadmin <at> gnu.org.
[Message part 3 (message/rfc822, inline)]
[Message part 4 (text/plain, inline)]
I'm not sure if we are supposed to report infrastructure problems as Emacs bugs, but it should be easy to close if not. I, and at least a few others, have had TLS connection problems to GNU ELPA in the last day or two, with the errors:
|Issued by: R3
|Issued to: CN=elpa.gnu.org
|Hostname: elpa.gnu.org
|Public key: RSA, signature: RSA-SHA256
|Protocol: TLS1.3, key: ECDHE-RSA, cipher: AES-256-GCM, mac: AEAD
|Security level: Medium
|Valid: From 2021-09-28 to 2021-12-27
|
|
|The TLS connection to elpa.gnu.org:443 is insecure for the following
|reasons:
|
|certificate has expired
|certificate could not be verified
It appears that elpa.gnu.org is returning a certificate chain referring to a root certificate that expired today. (More info: https://twitter.com/letsencrypt/status/1443621997288767491) I don't know if GnuTLS is supposed to be able to work around this (Firefox seems to, for instance), but I think it's a safe bet this is the cause of these connection errors.
I confirmed the chain that Emacs is seeing a couple ways. In Emacs 28, the security prompt lets you view certificate details by hitting "d", and in that window I confirmed it is seeing the root cert "CN=DST Root CA X3,O=Digital Signature Trust Co."
I also attached the chain I got by running:
openssl s_client -showcerts -servername elpa.gnu.org -connect elpa.gnu.org:443
Thanks!
[chain.pem (application/x-x509-ca-cert, attachment)]
This bug report was last modified 3 years and 231 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.