DST Root CA X3 will expire on September 30, 2021
That means those older devices that don’t trust ISRG Root X1 will start getting certificate warnings when visiting sites that use Let’s Encrypt certificates.
ISRG Root X1 is in the Windows certificate store.
I guess the reason TortoiseHG fails is because it uses "certifi" (which "provides Mozilla’s carefully curated collection of Root Certificates" https://pypi.org/project/certifi/ ) instead of just using the normal Windows certificate store.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
AFAIK, it does try to use the Windows certificate store. We had some Windows machines several years ago that would get a similar error message because the intermediate certificate was missing, and it was fixed by visiting the website in IE so that it would download the certificate (via Windows updates?) and put it into the store. I added the debugssl command to hg do that without IE.
It looks like both hg and thg are bundling some old versions of certifi- both have references to 2019 and 2020 packages. Does this happen with the vanilla hg installer? What server are you using that has a problem? I didn't see an issue with mercurial-scm.org today, even though there were other certificate issues related to this.
(The server is not public.)
I saw debugssl but running it unfortunately did not fix the problem:
% hg debugssl --verbosechecking the certificate chainfull certificate chain is available[command completed successfully Sat Oct 2 09:30:36 2021]% hg incoming(the full certificate chain may not be available locally; see "hg help debugssl")URLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:727)[command returned code 255 Sat Oct 2 09:30:55 2021]
When visiting the server with IE, there's no problem and the IE lock-icon says "ISRG Root X1 has identified this site as ...".
Is there some way to see the certificates TortoiseHG uses and where they come from?
Is there some way to see the certificates TortoiseHG uses and where they come from?
I don't think TortoiseHg is using certificates for anything- I think core hg should be doing the work here. It ultimately uses python to do the verification. I have a bad feeling the OpenSSL version is also playing a role here- IDK that py2 uses a new enough version.
Here's what you can do to help narrow down the problem.
Create a virtualenv in py2.7, and pip install mercurial. Does that have the same problem? Does it resolve if you pip install the latest certifi?
Create a venv in py3.9, and pip install mercurial. Same questions as (1)
Py2.7 support is going away very soon, so if there's something that can be done to work around that problem (because the thg py3 packaging on Windows still needs to be figured out, and might linger a bit), it would be helpful to figure out now.
In the meantime if you need to use this server, I suspect you can use the --insecure option for network commands. I'm pretty sure there's also something in the [hostsecurity] config that can make this server specific. Or you might be able to bypass the certificate verification by putting in the host fingerprint.
I had success visiting https://foss.heptapod.net with a browser, finding and downloading the chained PEM file, saving that to disk, and then adding this to my repo's .hg/hgrc
$ py -2.7Python 2.7.17 (v2.7.17:c2f86d86e6, Oct 19 2019, 21:01:17) [MSC v.1500 64 bit (AMD64)] on win32Type "help", "copyright", "credits" or "license" for more information.>>> import certifi>>> certifi.where()'C:\\Python27\\lib\\site-packages\\certifi\\cacert.pem'>>> import sys>>> sys.path['', 'C:\\WINDOWS\\SYSTEM32\\python27.zip', 'C:\\Python27\\DLLs', 'C:\\Python27\\lib', 'C:\\Python27\\lib\\plat-win', 'C:\\Python27\\lib\\lib-tk', 'C:\\Python27', 'C:\\Python27\\lib\\site-packages']>>> exit()
But in TortoiseHG's debugshell it does not:
$ "c:\Program Files\TortoiseHg\hg.exe" debugshellPython 2.7.18 (v2.7.18:8d21aa21f2, Apr 20 2020, 13:25:05) [MSC v.1500 64 bit (AMD64)] on win32Type "help", "copyright", "credits" or "license" for more information.(InteractiveConsole)>>> import certifi>>> certifi.where()Traceback (most recent call last): File "<console>", line 1, in <module> File "hgdemandimport\demandimportpy2.pyo", line 157, in __getattr__ File "hgdemandimport\demandimportpy2.pyo", line 97, in _load File "hgdemandimport\demandimportpy2.pyo", line 44, in _hgextimportImportError: No module named certifi>>> import sys>>> sys.pathTraceback (most recent call last): File "<console>", line 1, in <module> File "hgdemandimport\demandimportpy2.pyo", line 158, in __getattr__AttributeError: 'module' object has no attribute 'paths'>>> sys.path['c:\\Program Files\\TortoiseHg\\lib\\library.zip', 'C:\\Users\\peter\\AppData\\Roaming\\Python\\Python27\\site-packages']
C:\Users\peter\AppData\Roaming\Python\Python27\site-packages does not exist. That to me explains why upgrading certifi did not help TortoiseHG. TortoiseHG uses the wrong import path for some reason.
(By TortoiseHG I mean "TortoiseHG and/or hg installed by the TortoiseHG installer".)
C:\Users\peter\AppData\Roaming\Python\Python27\site-packages does not exist. That to me explains why upgrading certifi did not help TortoiseHG. TortoiseHG uses the wrong import path for some reason.
This is the user site-package, and it's added to sys.path unconditionally at startup to allow 3rd party extensions to be loaded with trivial syntax. IDK if there's an issue with also adding the system site-package to sys.path- someone else just added the user site to the mac builds, and I copied it for Windows.
In any event, if you run py -2 -m pip install --user certifi, it will get installed into the user site, and you won't need admin rights to do it. I think the user site is preferred in general, so you don't pollute the main python installation. That said, it sounds like it's not fixed in certifi yet either: https://github.com/certifi/python-certifi/pull/162
I stumbled across a Windows machine that has the same SSL error, but it's ancient (Windows 2019 Server 1809 build 17763.2213). Installing certifi 2021.10.8 didn't help. I'm going to see if the machine can be upgraded tomorrow, but it's not mine, so that may not happen right away. I'm still not seeing it on my Windows 10 21H1 install. What version of Windows are you on, and are there updates to install?
The machine that was affected does not seem to be affected anymore.
Currently it has Windows 10 20H2 build 19042.1237.
According to Windows' "View update history" one "Quality Update" (KB4023057) various driver updates and anti-virus definition updates were installed in the meantime, but I have no idea if that really is related.
Thanks for the help, and please feel free to close this issue (or leave it open if you want to investigate more).
Thanks for playing along. I guess I'll close this because I'm pretty convinced that this looks at the system certificates by default, and certifi is refusing to remove the broken cert until the change comes from their upstream. So not much we can do, though it works on relatively recently updated Windows builds as-is.