error: No version of gnu-elpa-keyring-update >= nil is available

[tianywan]

I find the issue #721 (#721) could be reproduced on this version of emacs configuration on RHEL 8.0.
The error "No version of gnu-elpa-keyring-update >= nil is available" is reported during the stage of initiation, and the following error could also be found in the output of "emacs --debug-init":

Debugger entered--Lisp error: (file-error "https://elpa.gnu.org/packages/archive-contents" "Bad Request")
signal(file-error ("https://elpa.gnu.org/packages/archive-contents" "Bad Request"))
package--download-one-archive(("gnu" . "https://elpa.gnu.org/packages/") "archive-contents" nil)
package--download-and-read-archives(nil)
package-refresh-contents()

On the issue #721, I worked around it by replacing "https" with "http" in init-elpa.el, which is not worked for this version any more. I post this problem here because I believe there must be someone who knows the root cause and maybe can give me some help.
Any reply is very appreciated!

The following is some information for reference:

1. I believe this is different from issue Package undo-tree is unavailable and Failed to download 'gnu' archive. Bad request. (Solution included) syl20bnr/spacemacs#12535,
   because I find the rescue method has already been imported into init-elpa.el:

(setq gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3")

2. my emacs version is:

[user1@localhost ~]$ emacs --version
GNU Emacs 26.1
Copyright (C) 2018 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

3. my emacs can open something like "https://www.yahoo.com", but cannot open "https://elpa.gnu.org". This may has little relation to the GFW(Great Firewall of China), because I can open https://elpa.gnu.org from firefox browser.

4. Some thing on ELPA's certificate chains of my certifacates:
   4.1 output of "gnutls-cli-debug"

[[email protected]]$ gnutls-cli-debug elpa.gnu.org
GnuTLS debug client 3.6.5
Checking elpa.gnu.org:443
whether we need to disable TLS 1.2... no
whether we need to disable TLS 1.1... no
whether we need to disable TLS 1.0... no
whether %NO_EXTENSIONS is required... yes
whether %COMPAT is required... no
for TLS 1.0 (RFC2246) support... yes
for TLS 1.1 (RFC4346) support... yes
for TLS 1.2 (RFC5246) support... yes
for TLS 1.3 (RFC8446) support... yes
|<1>| FFDHE groups advertised, but server didn't support it; falling back to server's choice
TLS1.2 neg fallback from TLS 1.6 to... TLS1.2
for inappropriate fallback (RFC7507) support... yes
for HTTPS server name... Apache/2.4.38 (Debian)
for certificate chain order... sorted
for safe renegotiation (RFC5746) support... yes
for encrypt-then-MAC (RFC7366) support... yes
for ext master secret (RFC7627) support... yes
for heartbeat (RFC6520) support... no
for version rollback bug in RSA PMS... dunno
for version rollback bug in Client Hello... no
whether the server ignores the RSA PMS version... no
whether small records (512 bytes) are tolerated on handshake... no
whether cipher suites not in SSL 3.0 spec are accepted... yes
whether a bogus TLS record version in the client hello is accepted... yes
whether the server understands TLS closure alerts... yes
whether the server supports session resumption... yes
for anonymous authentication support... no
|<1>| FFDHE groups advertised, but server didn't support it; falling back to server's choice
for ephemeral Diffie-Hellman support... yes
|<1>| FFDHE groups advertised, but server didn't support it; falling back to server's choice
for RFC7919 Diffie-Hellman support... no
for ephemeral EC Diffie-Hellman support... yes
for curve SECP256r1 (RFC4492)... yes
for curve SECP384r1 (RFC4492)... yes
for curve SECP521r1 (RFC4492)... yes
for curve X25519 (RFC8422)... yes
for AES-GCM cipher (RFC5288) support... yes
for AES-CCM cipher (RFC6655) support... yes
for AES-CCM-8 cipher (RFC6655) support... yes
for AES-CBC cipher (RFC3268) support... yes
for CAMELLIA-GCM cipher (RFC6367) support... no
for CAMELLIA-CBC cipher (RFC5932) support... yes
for 3DES-CBC cipher (RFC2246) support... no
for ARCFOUR 128 cipher (RFC2246) support... no
|<1>| FFDHE groups advertised, but server didn't support it; falling back to server's choice
for CHACHA20-POLY1305 cipher (RFC7905) support... yes
for MD5 MAC support... no
for SHA1 MAC support... yes
for SHA256 MAC support... yes
for max record size (RFC6066) support... no
for OCSP status response (RFC6066) support... no

4.2 output of "gnutls-cli elpa.gnu.org":

Processed 148 CA certificate(s).
Resolving 'elpa.gnu.org:443'...
Connecting to '209.51.188.89:443'...

• Certificate type: X.509

• Got a certificate list of 2 certificates.

• Certificate[0] info:

• subject CN=elpa.gnu.org', issuer CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', serial " ****** ", RSA key 2048 bits, signed using RSA-SHA256, activated 2020-02-04 06:13:39 UTC', expires 2020-05-04 06:13:39 UTC', pin-sha256=" ****** "
  Public Key ID:
  sha1:******
  sha256:******
  Public Key PIN:
  pin-sha256:******

• Certificate[1] info:

• subject CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', issuer CN=DST Root CA X3,O=Digital Signature Trust Co.', serial " ****** ", RSA key 2048 bits, signed using RSA-SHA256, activated 2016-03-17 16:40:46 UTC', expires 2021-03-17 16:40:46 UTC', pin-sha256=" ****** "

• Status: The certificate is trusted.

• Description: (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)

• Options:

• Handshake was completed

• Simple Client Mode:

HTTP/1.1 400 Bad Request
Date: Mon, 23 Mar 2020 08:52:17 GMT
Server: Apache/2.4.38 (Debian)
Content-Length: 297
Connection: close
Content-Type: text/html; charset=iso-8859-1

<title>400 Bad Request</title>

Bad Request

Your browser sent a request that this server could not understand.

---

Apache/2.4.38 (Debian) Server at elpa Port 443 - Peer has closed the GnuTLS connection

4.3 output of emacs with command of M-: (gnutls-available-p)
(ClientHello\ Padding Key\ Share Post\ Handshake\ Auth PSK\ Key\ Exchange\ Modes Cookie Supported\ Versions Early\ Data Pre\ Shared\ Key Se
ssion\ Ticket Record\ Size\ Limit Extended\ Master\ Secret Encrypt-then-MAC ...)

[tianywan]

I find some information on this problem. https://emacs.stackexchange.com/questions/26335/emacs-behind-firewall-cannot-download-packages-from-melpa

[amittendulkar]

I am getting the same issue on RHEL 8. However, I am not inside any firewall. I just spun up an Amazon EC2 RHEL8 instance and cloned the repo.

The command wget https://elpa.gnu.org/packages/archive-contents is downloading the content properly but emacs --debug-init is showing "Bad Request" error. What might be wrong?

ec2-user@ip-10-0-0-228 ~]$ emacs --version
GNU Emacs 26.1
Copyright (C) 2018 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

Adding debug-init output,

Debugger entered--Lisp error: (file-error "https://elpa.gnu.org/packages/archive-contents" "Bad Request")
  signal(file-error ("https://elpa.gnu.org/packages/archive-contents" "Bad Request"))
  package--download-one-archive(("gnu" . "https://elpa.gnu.org/packages/") "archive-contents" nil)
  package--download-and-read-archives(nil)
  package-refresh-contents()

Starting with emacs -q and running M-x package-list-packages gave me the below error (copy-pasting from *Messages*),

Loading /usr/share/emacs/site-lisp/site-start.d/desktop-entry-mode-init.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Importing package-keyring.gpg...done
You can run the command `package-list-packages' with M-x pa-l- RET
Package refresh done
error in process sentinel: Error retrieving: https://elpa.gnu.org/packages/archive-contents "incomprehensible buffer" [2 times]