Broken certificate verification since 3.1.1 / openssl 1.1.1h

[Kriechi]

Hi all,

we are experiencing multiple test failures in the mitmproxy project since the release of cryptography 3.1.1.

I can confirm that all tests are green with cryptography 3.1.0. As soon as I install cryptography 3.1.1 in a clean venv, I get multiple test failures from code we basically haven't touched in years.

Looking through the changelog of cryptography, I don't see anything that jumps out - it only lists a version bump to OpenSSL 1.1.1h (from 1.1.1g)

The errors or exception we are seeing with newer versions are:

• OpenSSL.SSL.Error: [('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')]
• Certificate verification error for example.mitmproxy.org: self signed certificate (errno: 18, depth: 0)

Here a failing test run a few days after the cryptography 3.1.1 release (picked up through our semver selector): https://github.com/mitmproxy/mitmproxy/runs/1177356771?check_suite_focus=true

And a green test run with the older cryptography 3.1.0 from early September:
https://github.com/mitmproxy/mitmproxy/runs/1086372460?check_suite_focus=true

This happens on Ubuntu, macOS, and Windows.
This happens with Python 3.6, 3.7, 3.8, and also the new 3.9.
certifi==2020.6.20
cffi==1.14.3
idna==2.10
pyOpenSSL==19.1.0
pip 20.2.4

This problem still happens with cryptography 3.2.0 and the latest 3.2.1.

The easiest way to reproduce for now is taking the mitmproxy test suite and running one of the failing tests directly:

git clone https://github.com/mitmproxy/mitmproxy.git
cd mitmproxy
tox -r -e py39 -- test/mitmproxy/net/test_tcp.py::TestSSLUpstreamCertVerificationWBadHostname::test_mode_none_should_pass_without_sni
tox -r -e py39 -- test/mitmproxy/net/test_tcp.py::TestSSLUpstreamCertVerificationWValidCertChain::test_mode_strict_w_pemfile_should_pass

which will fail with two different looking errors on cryptography>=3.1.1 , and succeed with cryptography==3.1.0, configured in the our setup.py.

If needed I can try and break down the test to a minimal viable failing test code.

I'm not too familiar with the dependency chain behind cryptography/pyca/pyopenssl/openssl - but this problem might very well be in OpenSSL itself (would be surprising though if nobody else has caught it yet?)

[reaperhulk]

I think we'll want a minimum reproducer. Given that this is happening across all 3 platforms you test it's possible this is indeed an OpenSSL change. https://github.com/openssl/openssl/compare/OpenSSL_1_1_1g..OpenSSL_1_1_1h is the diff between g and h, but it's pretty large so finding relevant changes here may be challenging.

[mhils]

This likely is an OpenSSL change - I can't reproduce this locally with latest cryptography an older OpenSSL version.

[Kriechi]

Apparently OpenSSL changed something around having different CN for root and leaf certificates. I didn't see anything the changelog - but clearly not a cryptography issue therefore.
https://www.openssl.org/news/changelog.html#openssl-111

Fixed via mitmproxy/mitmproxy#4255