Multiple concurrent client certs broken with v2.32.3 about requests

[nateprewitt]

Thanks for the report, @jeffreytolar. It does looks like we're not checking the certs provided by the Session before opting into the default context, I've put together fe251aa to disable the default context when certs are present.

However, with testing I'm seeing an exception with the cert being self-signed that wasn't present in 2.31.0. I'm looking into that further but would you mind checking the above patch against your current setup so we can decouple the two issues. If your issue is persisting after we've moved the default context out of the hot path, there may be something else at play with the recent CVE fix.

[jeffreytolar]

So far it's looking like that patch is working in our main setup - thanks for the quick commit!

For the self-signed issue still in the reproducer, I think it's that 2.32.x isn't passing a CA bundle to urllib3, whereas 2.31 did that here:

requests/requests/adapters.py

Lines 257 to 258 in 147c851

	if not cert_loc:
	cert_loc = extract_zipped_paths(DEFAULT_CA_BUNDLE_PATH)

; that causes urllib3 to load the OS default, rather than using certifi

To restore the v2.31 behavior, I think maybe a elif verify is True: pool_kwargs["ca_certs (or ca_cert_dir)"] = extract_zipped_paths(DEFAULT_CA_BUNDLE_PATH) might work in _urllib3_request_context ?

[sigmavirus24]

So far it's looking like that patch is working in our main setup - thanks for the quick commit!

For the self-signed issue still in the reproducer, I think it's that 2.32.x isn't passing a CA bundle to urllib3, whereas 2.31 did that here:

requests/requests/adapters.py

Lines 257 to 258 in 147c851

	if not cert_loc:
	cert_loc = extract_zipped_paths(DEFAULT_CA_BUNDLE_PATH)

; that causes urllib3 to load the OS default, rather than using certifi

To restore the v2.31 behavior, I think maybe a elif verify is True: pool_kwargs["ca_certs (or ca_cert_dir)"] = extract_zipped_paths(DEFAULT_CA_BUNDLE_PATH) might work in _urllib3_request_context ?

Yeah, I thought the optimization broke the zipped paths extraction but couldn't prove it easily

[nateprewitt]

Ok, so that's the same issue reported here (#6710 (comment)) this morning. That explains why calling load_default_certs on the SSLContext fixes it.

Let me take a closer look tomorrow, I'm a little worried if we do it only for verify is True that we'll start the whole custom SSLContext issue over again. Thanks for pointing that out, @jeffreytolar!