GNU bug report logs - #51038
27.2; ELPA certificate not trusted on Windows

Previous Next

Full log

View this message in rfc822 format

From: John Cummings <john <at> rootabega.net>
To: Michael Hoffman <emacs-hoffman <at> snkmail.com>
Cc: 51038 <at> debbugs.gnu.org
Subject: bug#51038: 27.2; ELPA certificate not trusted on Windows
Date: Tue, 05 Oct 2021 17:35:35 +0000

Hi Michael, I'm just a user, but I've run into this bug recently and have been researching the options as they relate to Emacs. I believe that this is what you should expect if you are using gnutls 3.6.12 and you have the expired X3 root cert in your trust store. As you're seeing, that version of gnutls treats the chain as expired because of the expired root, even though it could validate it due to the alternate path leading to the ISRG root. I confirmed both of those on my Emacs 27.2 Windows installation from the builds kindly published by GNU, which I assume you are using. Since this is a self-contained build not living in a package management system, I don't BELIEVE there is any good way to fix the root cause of the problem on your system without rebuilding Emacs with gnutls >= 3.6.14, so I'm not sure if the maintainers will close this, or slot it for the next Windows build that gets published.

But hopefully this is something you can address on your side for now. Since this is expected behavior, the least invasive thing to do is probably to decide to trust that certificate (a)lways, assuming you are confident in its identity. I am personally confident in that, because I verified that the key checksums Emacs is reporting do belong to elpa.gnu.org. You don't have to take my word for that; you can download the cert in a browser that you trust (which probably will not be experiencing this problem), and then dump the public key info with something like "certtool --infile=elpa-gnu-org.pem --pubkey". I believe that certtool is bundled in that Windows installation.

I was also able to bypass this problem by removing that expired X3 root cert from my list of trusted roots in Windows, but it seems risky and unnecessary compared with the previous option. So I'm not recommending that, just noting that it seems to work for me.

This issue could be addressed on the server side as well, but some services are choosing to leave this chain with the expired root in place. There are valid reasons to do this, and correct clients (like gnutls 3.6.14) should be able to handle it, but I don't know the specifics on why GNU has chosen to leave it so far.

Previous Next

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