[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#51038: 27.2; ELPA certificate not trusted on Windows

From: John Cummings
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 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]