The behavior of SSLContext.load_verify_locations is rather inconsistent across platforms:

On most POSIX platforms (Linux, BSD, non-Apple builds of OpenSSL) it loads certificates from predefined locations. The locations are defined during compile time and usually differ between vendors and platforms. My WiP "Improve TLS/SSL support" PEP lists all common locations and the packages that offer the certs. On these platforms SSL_CERT_DIR and SSL_CERT_FILE overwrite the location.

On Windows SSL_CERT_DIR and SSL_CERT_FILE are never taken into account by SSLContext.load_verify_locations because it doesn't call SSLContext.set_default_verify_paths(). The attached patch is a semi-fix for the problem. With the patch certs from SSL_CERT_DIR and SSL_CERT_FILE are only *added* to trusted root CA certs. The certs from Windows' cert store 'CA' and 'ROOT' are still loaded.

On OSX with Apple's custom build of OpenSSL SSL_CERT_DIR and SSL_CERT_FILE take effect. But there is a twist! In case a root CA cert is not found Apple's Trust Evaluation Agent (TEA) kicks in and looks up certs from Apple's keychain. It's almost the same situation as on Windows but more magical. In order to disable TEA one has to set the env var OPENSSL_X509_TEA_DISABLE=1 *before* the first cert is validated. After that the env var has no effect as the value is cached. Hynek has documted it in his blog: https://hynek.me/articles/apple-openssl-verification-surprises/

Does this effect anything besides causing SSL_CERT_DIR and SSL_CERT_FILE to be respected?

'to respect' is the wrong term. </nitpicking>

The patch makes the code use the two env vars. Even with my patch the function doesn't respect SSL_CERT_DIR and SSL_CERT_FILE because Windows' cert store is still in use. On Linux and BSD the two env vars replace the default locations.

Do we have tests for SSL_CERT_DIR and SSL_CERT_FILE being "respected"?
Otherwise, it might make sense to add one.

There is only a test case for ssl.get_default_verify_paths(), but not for SSLContext or SSLSocket.

Attached patch also adds a test -- I'm not convinced this is the best way to test this, but I don't see any other way either.

New changeset d9c52836aec8 by Benjamin Peterson in branch '2.7':
also use openssl envvars to find certs on windows (closes #22449)
https://hg.python.org/cpython/rev/d9c52836aec8

New changeset e1f453e13f8d by Benjamin Peterson in branch '3.4':
also use openssl envvars to find certs on windows (closes #22449)
https://hg.python.org/cpython/rev/e1f453e13f8d

New changeset f1113c568c60 by Benjamin Peterson in branch 'default':
merge 3.4 (#22449)
https://hg.python.org/cpython/rev/f1113c568c60

New changeset 3551bf16ee5c25b6349209dd30e032f0f3b9ace3 by LincolnPuzey in branch 'main':
bpo-45457: Minor fix to documentation for SSLContext.load_default_certs. (GH-28947)
https://github.com/python/cpython/commit/3551bf16ee5c25b6349209dd30e032f0f3b9ace3

New changeset 71f602b54c9c5346d22a542e186746b06cccfc8e by Miss Islington (bot) in branch '3.10':
bpo-45457: Minor fix to documentation for SSLContext.load_default_certs. (GH-28947) (GH-29373)
https://github.com/python/cpython/commit/71f602b54c9c5346d22a542e186746b06cccfc8e

New changeset 4ab6e524abd2d7f21c2d7a6eaee5be1f93baf140 by Miss Islington (bot) in branch '3.9':
bpo-45457: Minor fix to documentation for SSLContext.load_default_certs. (GH-28947) (GH-29374)
https://github.com/python/cpython/commit/4ab6e524abd2d7f21c2d7a6eaee5be1f93baf140