GNU bug report logs - #24396
25.1; Doesn't trust Let's Encrypt certificates (used by MELPA)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 24396 in the body.
You can then email your comments to 24396 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Zack Weinberg <zackw <at> panix.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.1; Doesn't trust Let's Encrypt certificates (used by MELPA)
Date: Thu, 8 Sep 2016 13:36:06 -0400

Emacs 25.1-rc2 (prebuilt for OSX, from
https://emacsformacosx.com/emacs-builds/Emacs-pretest-25.1-rc2-universal.dmg)
does not accept TLS certificates issued by Let's Encrypt
(https://letsencrypt.org/).  This is a particular problem because MELPA
(specifically, https://stable.melpa.org) uses such a certificate.

To observe the problem, run these Lisp commands:

---
(require 'package)
(add-to-list 'package-archives
             '("melpa-stable" . "https://stable.melpa.org/packages/"))
(package-initialize)
(package-list-packages)
---

You will get a transient *Network Security Manager* buffer reading

---
Certificate information
Issued by:          Let's Encrypt Authority X3
Issued to:          CN=stable.melpa.org
Hostname:           stable.melpa.org
Public key:         RSA, signature: RSA-SHA256
Protocol:           TLS1.2, key: ECDHE-RSA, cipher: AES-128-GCM, mac: AEAD
Security level:     Medium
Valid:              From 2016-09-04 to 2016-12-03


The TLS connection to stable.melpa.org:443 is insecure for the
following reasons:

the certificate was signed by an unknown and therefore untrusted authority
certificate could not be verified
---

and a prompt asking whether to continue connecting.

(Incidentally, the *Network Security Manager* buffer is deleted after
you answer the question, and C-x o or clicking in that buffer counts
as answering "no".  This makes it annoyingly difficult to capture the
contents of that buffer in order to, say, include it in a bug report.)

zw


In GNU Emacs 25.1.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21
Version 10.9.5 (Build 13F1911))
 of 2016-08-21 built on builder10-9.porkrind.org
Windowing system distributor 'Apple', version 10.3.1404
Configured using:
 'configure --with-ns '--enable-locallisppath=/Library/Application
 Support/Emacs/${version}/site-lisp:/Library/Application
 Support/Emacs/site-lisp''

Configured features:
NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  show-paren-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:

Type C-x 1 to delete the help window.
Failed to download ‘melpa-stable’ archive.
Mark set
Package refresh done
No apropos matches for ‘security’

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug sendmail apropos mm-archive message
rfc822 mml mml-sec epg mailabbrev gmm-utils mailheader mm-decode
mm-bodies mm-encode url-handlers mail-utils network-stream nsm starttls
url-http tls gnutls mail-parse rfc2231 rfc2047 rfc2045 ietf-drums url-gw
url-cache url-auth url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util url-parse url-vars mailcap
server paren cus-start cus-load tramp tramp-compat auth-source cl-seq
eieio eieio-core cl-macs gnus-util mm-util help-fns mail-prsvr
password-cache tramp-loaddefs trampver shell pcomplete comint ansi-color
ring format-spec advice dired finder-inf package epg-config seq byte-opt
gv bytecomp byte-compile cl-extra help-mode easymenu cconv cl-loaddefs
pcase cl-lib time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel ns-win ucs-normalize
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
kqueue cocoa ns multi-tty make-network-process emacs)

Memory information:
((conses 16 239636 56351)
 (symbols 48 24300 0)
 (miscs 40 83 256)
 (strings 32 29846 8346)
 (string-bytes 1 864838)
 (vectors 16 38677)
 (vector-slots 8 714931 12891)
 (floats 8 248 88)
 (intervals 56 698 735)
 (buffers 976 22))

Message #8 received at 24396 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Zack Weinberg <zackw <at> panix.com>
Cc: 24396 <at> debbugs.gnu.org
Subject: Re: bug#24396: 25.1;
 Doesn't trust Let's Encrypt certificates (used by MELPA)
Date: Fri, 09 Sep 2016 13:04:16 -0400

Zack Weinberg wrote:

> Emacs 25.1-rc2 (prebuilt for OSX, from
> https://emacsformacosx.com/emacs-builds/Emacs-pretest-25.1-rc2-universal.dmg)
> does not accept TLS certificates issued by Let's Encrypt
> (https://letsencrypt.org/).

It works fine for me on RHEL7.

I believe the trusted certs are specified by the gnutls-trustfiles
variable. Perhaps you need to explicitly add wherever they live on your
system, and/or perhaps the default needs to be improved for Mac OS X.

> (Incidentally, the *Network Security Manager* buffer is deleted after
> you answer the question, and C-x o or clicking in that buffer counts
> as answering "no". 

This sounds like a separate issue that should be fixed.

Message #13 received at 24396 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Zack Weinberg <zackw <at> panix.com>
Cc: 24396 <at> debbugs.gnu.org
Subject: Re: bug#24396: 25.1;
 Doesn't trust Let's Encrypt certificates (used by MELPA)
Date: Fri, 09 Sep 2016 15:55:48 -0400

http://emacs.stackexchange.com/questions/18045/how-can-i-retrieve-an-https-url-on-mac-os-x-without-warnings-about-an-untrusted

seems relevant.

I guess OS X uses some system keychain for SSL certs that is opaque to Emacs.
Perhaps it should learn to understand it, if that's even possible.

There's a suggested workaround related to libressl there.

Message #16 received at 24396 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 24396 <at> debbugs.gnu.org, zackw <at> panix.com
Subject: Re: bug#24396: 25.1;
 Doesn't trust Let's Encrypt certificates (used by MELPA)
Date: Sat, 10 Sep 2016 08:46:19 +0300

> From: Glenn Morris <rgm <at> gnu.org>
> Date: Fri, 09 Sep 2016 15:55:48 -0400
> Cc: 24396 <at> debbugs.gnu.org
> 
> http://emacs.stackexchange.com/questions/18045/how-can-i-retrieve-an-https-url-on-mac-os-x-without-warnings-about-an-untrusted
> 
> seems relevant.
> 
> I guess OS X uses some system keychain for SSL certs that is opaque to Emacs.
> Perhaps it should learn to understand it, if that's even possible.

Isn't that the GnuTLS job?  (The OP's build is linked against GnuTLS.)
That's what happens on MS-Windows: GnuTLS uses the system-wide
certificate store, not the files you find on a typical Posix box.  We
already request GnuTLS to use system certificate store.

Message #21 received at 24396 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Zack Weinberg <zackw <at> panix.com>
Cc: 24396 <at> debbugs.gnu.org
Subject: Re: bug#24396: 25.1;
 Doesn't trust Let's Encrypt certificates (used by MELPA)
Date: Tue, 26 Sep 2017 11:45:18 -0400

Glenn Morris wrote:

> I believe the trusted certs are specified by the gnutls-trustfiles
> variable. Perhaps you need to explicitly add wherever they live on your
> system, and/or perhaps the default needs to be improved for Mac OS X.

https://debbugs.gnu.org/28603#5

says that such a change worked.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.