8

My environment:

  • Linux Mint 17.3 (based on Ubuntu 14.04)
  • Emacs 25.3.1

  • The value of package-archives:

    (("gnu" . "https://elpa.gnu.org/packages/") ("melpa" . "https://melpa.org/packages/") ("marmalade" . "https://marmalade-repo.org/packages/"))

When I ran M-x list-packages, the minibuffer shows:

"Continue connecting? (No, Session only, Always)".

While a *Nework Security Manager* buffer shows up with some information, and the error:

The TLS connection to elpa.gnu.org:443 is insecure for the following reason:

certificate could not be verified

Please see the attached picture for the detail.

I could choose Session only to proceed though.

What debugging technique is available to help narrow down the issue?

enter image description here

York
  • 221
  • 2
  • 5
  • What happens when you access https://elpa.gnu.org wit your browser? – Arkadiusz Drabczyk Dec 31 '17 at 14:46
  • Anyway, I cannot reproduce it with `Emacs 25.3.1` on `Slackware 14.2` – Arkadiusz Drabczyk Dec 31 '17 at 14:47
  • @ArkadiuszDrabczyk I can access https://elpa.gnu.org/packages without error. – York Dec 31 '17 at 15:14
  • some people report that they started to experience such problems after installing `prelude`: https://github.com/bbatsov/prelude/issues/1115 – Arkadiusz Drabczyk Dec 31 '17 at 15:15
  • I've never used prelude, but my own customization. – York Dec 31 '17 at 18:12
  • Does the problem still persist when you run `emacs -q`? – Arkadiusz Drabczyk Dec 31 '17 at 19:56
  • @ArkadiuszDrabczyk Sorry for responding late. To my surprise, the problem went away when I ran `emacs -Q`. I never expected this because I was misled by the output of running `gnutls elpa.gnu.org` from bash shell, where it reported: `Peer's certificate issuer is unknown Peer's certificate is NOT trusted` Further more, I've found out that it was `(require 'cask "~/.cask/cask.el") (eval-and-compile (cask-initialize))` that caused the problem. I had a [closed issue in `cask`](https://github.com/cask/cask/issues/409). – York Jan 02 '18 at 03:42
  • As discussed in that ticket, this is not caused by Cask. The default `package-archives` list in Emacs 25.3 uses insecure access. Cask defaults to secure (possible Prelude does too; I don't use it). It's very likely that you have an underlying issue with your TLS setup. Emacs 26 will use HTTPS by default and thus will be broken even without Cask/Prelude (unless the underlying issue is resolved). – Sam Brightman Jan 27 '18 at 18:25

1 Answers1

1

After much digging, I believe a common cause of this is likely a combination of two things:

  1. elpa.gnu.org is misconfigured, sending its own certificate in duplicate before the issuer certificate - this counts as an out-of-order certificate problem. This can be confirmed using gnutls-cli or openssl s_client. I have notified the maintainer.
  2. A lack of functionality to re-order such out-of-order chains in GnuTLS prior to version 3. In particular, the bug is still present in 2.12.23 which is used to build EVM's Travis binaries and a common Travis build environment.

Note that there are other potential configuration and environment issues that can cause this and similar problems. Provided you have everything else set up correctly though, this seems likely.

Sam Brightman
  • 170
  • 7