TestRequests.test_pyopenssl_redirect is broken in CI

TestRequests.test_pyopenssl_redirect is broken in CI.

I just fixed the urllib3 integration tests to work on GitHub Actions in https://github.com/urllib3/urllib3/pull/2304, and noticed that TestRequests.test_pyopenssl_redirect is broken, and is broken on your CI as well. 

## Expected Result

The test should pass.

## Actual Result

The test reliably fails, on all Python 3.6+ versions: https://github.com/psf/requests/runs/2715203297. Interestingly, it works on 2.7 and 3.5.

## Reproduction Steps

Run you CI: https://github.com/psf/requests/runs/2715203297

## System Information

Fails on Linux, Windows and macOS. Also on PyPI. But only on Python 3.6+.

Thanks for filing an issue, @pquentin! We first saw this a couple weeks ago but I haven't had a chance to track down the issue. We have both our httpbin/pytest-httpbin dependencies pinned, so they shouldn't have changed, unless an underlying dependency was recently updated. The local endpoint is now terminating the connection when we attempt to make our test call, causing the failure.

We're technically removing first-class support for pyopenssl in the next release. Seth started that process in 2.25.0, and we'll be turning `requests[security]` into a no-op in 2.26.0. We'll need to do a little digging to understand the failure, then decide if we can fix or if removing the test is accessible. We can track that outstanding work here if anyone has any leads in the meantime.

I work on the Python packaging team for SUSE, and I've been trying to nail down this issue myself. I strongly suspect the culprit is Werkzeug 2.0.1 (installing Werkzeug 1.0.1 makes the test pass), but given the massive amount of changes I'm struggling to nail down which change causes it.

Thanks @nateprewitt and @s-t-e-v-e-n-k!

So that explains why this works in Python 2.7 and Python 3.5: werkzeug 2 does not support those versions. I ran `git bisect` and the test starts to fail in https://github.com/pallets/werkzeug/pull/2003. Unfortunately this pull request changes 2,800 lines of code. (I tested this with Flask 1.1.4, not sure if it makes a difference.)

Has anyone filed a bug with werkzeug? If this is related to upgrading that package it sounds like a regression to me that they need to fix. Given this is part of a redirect test, I also noticed Tom Christie filed a bug about double-encoding redirects which sounds like it _might_ be related

If anyone can formulate a standalone minimal example, I can try to help debug it.

Thanks @davidism! It appears to only be [one test](https://github.com/psf/requests/blob/main/tests/test_requests.py#L882-L883) that's broken around pyopenssl. The SSL handshake is failing and the server is closing the connection. It's using a [certificate bundle fixture](https://github.com/kevin1024/pytest-httpbin/blob/be3c3205972195ca632949ed7af1dc7086cb7899/pytest_httpbin/plugin.py#L39-L41) from pytest-httpbin which is just overriding our cert bundle with this [cert](https://github.com/kevin1024/pytest-httpbin/blob/be3c3205972195ca632949ed7af1dc7086cb7899/pytest_httpbin/certs/cacert.pem). Presumably, Flask did something like dropping support for Common Names or some other security improvement that's making this certificate non-negotiable.

This is an [example build](https://github.com/nateprewitt/requests/actions/runs/1867367516) of the failure but the stacktrace isn't terribly helpful. The connection is being aborted with:
```
[SSL: HTTP_REQUEST] http request (_ssl.c:852)
```
 I was planning to start from the Werkzeug patch (https://github.com/pallets/werkzeug/pull/2003) and work backwards from there. If you have any insights though, that'd be greatly appreciated. I'll see if I can simplify the repro further so it's just a standalone script.



I've looked at the PR, and I really can't figure out why that broke this test, it was a big refactor but it shouldn't have affected TLS. It didn't modify `serving.py` at all, and Werkzeug's dev server is what would be handling TLS requests. Werkzeug extends Python's `http.server`, calling `ssl.wrap_socket`. You could check if you have an issue with the cert when using the built-in server directly.

Regarding redirects, I don't know what httpbin does, but we did change to using 307/308 redirects by default, but that was well before that PR. Is the first request successful and the redirect not, or is the initial request unsuccessful?

@nateprewitt This test is passing now, presumably since https://github.com/psf/requests/pull/5859. Should we close this issue in favor of #6070?

It's passing due to the infrastructure pinning for Flask<2.0 but the specific test is still failing with the upgrade. I'd originally had this as the "issue" and #6070 as the broader action item, but I'm fine merging the two. I'll resolve this in favor of the broader ticket.