[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
far.
- bug#51038: 27.2; ELPA certificate not trusted on Windows, Michael Hoffman, 2021/10/05
- bug#51038: 27.2; ELPA certificate not trusted on Windows,
John Cummings <=
- bug#51038: 27.2; ELPA certificate not trusted on Windows, Lars Ingebrigtsen, 2021/10/06
- bug#51038: 27.2; ELPA certificate not trusted on Windows, John Cummings, 2021/10/06
- bug#51038: 27.2; ELPA certificate not trusted on Windows, Eli Zaretskii, 2021/10/06
- bug#51038: 27.2; ELPA certificate not trusted on Windows, John Cummings, 2021/10/06
- bug#51038: 27.2; ELPA certificate not trusted on Windows, Eli Zaretskii, 2021/10/06
- bug#51038: 27.2; ELPA certificate not trusted on Windows, John Cummings, 2021/10/06
- bug#51038: 27.2; ELPA certificate not trusted on Windows, Michael Hoffman, 2021/10/06
- bug#51038: 27.2; ELPA certificate not trusted on Windows, Eli Zaretskii, 2021/10/06
- bug#51038: 27.2; ELPA certificate not trusted on Windows, John Cummings, 2021/10/06
bug#51038: 27.2; ELPA certificate not trusted on Windows, Ioannis Kappas, 2021/10/24