SSL troubleshooting on Windows

Augie Fackler raf at durin42.com
Wed Apr 12 17:02:41 EDT 2017


On Mon, Apr 10, 2017 at 01:02:19AM -0400, Matt Harbison wrote:
> I had a little adventure a couple of weeks ago, changing a certificate on
> the server.  I'm not sure if it's worth doing anything, or if this just
> serves as a heads up to others using Windows.
>
> We use SCM Manager (which uses tomcat) on CentOS, with Mercurial 4.0.2.  The
> certificate had expired over the weekend.  So the admin imported the new
> certificate into the tomcat keystore, saw that the main page loaded in a web
> browser (probably Chrome, and I think I subsequently tried FireFox), and
> declared victory.  But Mercurial was still failing the verification.  After
> a bit of fiddling around, he eventually imported the root and intermediate
> certificates for the chain into the keystore as well, and then Mercurial
> clients worked.  Except for one Windows machine.  (I'm a bit puzzled that
> the web browsers were OK with this config, but not Mercurial.)
>
> I was able to get the one failing machine working by temporarily setting the
> fingerprint.  After awhile of debugging, I realized that this is a python
> bug [1].  Basically, Windows doesn't ship with a full set of certificates,
> and instead downloads them on demand.  But python isn't triggering the
> download.  In this case, Windows had the root certificate and the leaf
> certificate from the website, but was missing the intermediate certificate.

This is actually a server misconfiguration: some browsers do AIA
chasing to mitigate missing intermediate certs (Chrome does, but
Firefox doesn't!), so strictly speaking the right fix is to adjust
your webserver on the CentOS box.

(Thanks to Alex Gaynor for confirming my intuition on this and filling
in some blanks.)

> So the "fix" was to load the main web page in Internet Explorer, which
> silently builds the certificate chain on Windows, and then Mercurial works.
> An additional problem is that the error message is the same for both this
> failure, and a real certificate problem.
>
> I started adding code to:
>
> 1) Detect and fix this without Internet Explorer via a debug function that
> calls CertGetCertificateChain()
> 2) Detect the problem when connecting, and print out a message pointing to
> the debug command
> 3) Just fix the problem when connecting, so that the debug command isn't
> necessary
>
> The problem is that you need to successfully connect to the server in order
> to get the certificate to pass to the Win32 function.  Since the connection
> fails if verification is on, a second (non verifying) connection needs to be
> established to get the certificate, and then a third (verifying) connection
> to retry the original.  Ugh.  I tried turning off SSL verification on
> Windows, so that only the first connection is needed.  It looks like there
> are Win32 functions that can also verify the certificate chain, so we
> shouldn't be missing any functionality.  But python doesn't return the
> non-binary certificate when verification is off, so another check we do
> fails [2].
>
> I assume the chance of landing this hacky code is about 0.  The other
> alternative seems to be to package certifi or similar in the binary Windows
> installers.

Sadly, that probably wouldn't fix this case because of the above.

> That was mentioned when Greg overhauled the SSL stuff last
> year, but I think it was deferred because there wasn't any real reason to
> when python can access the Windows certificate store.  Maybe this is a
> reason?

I'm going to lean on my above claim about server misconfiguration for now.

>
> [1] https://bugs.python.org/issue20916
> [2] https://www.mercurial-scm.org/repo/hg/file/e0dc40530c5a/mercurial/sslutil.py#l623
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


More information about the Mercurial-devel mailing list