bug#24396: 25.1; Doesn't trust Let's Encrypt certificates (used by MELPA)

bug#24396: 25.1; Doesn't trust Let's Encrypt certificates (used by MELPA)

[Zack Weinberg]

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))

bug#24396: 25.1; Doesn't trust Let's Encrypt certificates (used by MELPA)

[Glenn Morris]

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.

bug#24396: 25.1; Doesn't trust Let's Encrypt certificates (used by MELPA)

[Glenn Morris]

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.

bug#24396: 25.1; Doesn't trust Let's Encrypt certificates (used by MELPA)

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Fri, 09 Sep 2016 15:55:48 -0400
> Cc: 24396@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.

Re: bug#24396: 25.1; Doesn't trust Let's Encrypt certificates (used by MELPA)

[christopherpenrose]

This is still broken on 10.12.5.  I wonder if the chain certificate is misconfigured on https://stable.melpa.org/

bug#24396: 25.1; Doesn't trust Let's Encrypt certificates (used by MELPA)

[Glenn Morris]

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.