获取 SSL：将代理与 python 请求一起使用时出现 CERTIFICATE_VERIFY_FAILED答案

【问题标题】：Getting SSL: CERTIFICATE_VERIFY_FAILED when using proxy with python requests获取 SSL：将代理与 python 请求一起使用时出现 CERTIFICATE_VERIFY_FAILED
【发布时间】：2021-09-17 08:25:12
【问题描述】：

我正在尝试使用 requests 库在 python 中实现代理，但我一遍又一遍地收到相同的错误。这是我的代码：

proxies = {
        'http': 'http://127.0.0.1:24000',
        'https': 'https://127.0.0.1:24000',
    }
    resp = requests.get('https://api.myip.com', proxies=proxies)
    print(resp.text)

我正在使用 Bright Data 的代理管理器，我怀疑我的代理实现是错误的。我得到的错误是：

raise SSLError(e, request=request)
requests.exceptions.SSLError: HTTPSConnectionPool(host='api.myip.com', port=443): Max retries exceeded with url: / (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate in certificate chain (_ssl.c:1129)')))

我已经尝试过我在网上找到的解决方案，例如 verify=false，它适用于此链接，但不适用于我需要访问的其他链接，这就是我寻找更安全解决方案的原因。

【问题讨论】：

首先，https 代理设置应该指向http://... 而不是https://... - 至少如果您使用最新版本的请求。然后，如果您希望它更安全，那么您需要信任颁发相关证书的特定 CA。目前尚不清楚这是什么 CA。并且 verify=false 不适用于其他链接可能仅仅是因为这些是需要以不同方式处理的其他问题 - 但如果没有明确的错误，就不可能说出如何处理。
感谢您的回复。在我替换了代理设置后，它开始使用这个和其他 url。我会调查证书和其他错误。

标签： python ssl python-requests

【解决方案1】：

如果您有自签名证书和密钥的副本，您可以修改代码如下：

proxies = {
    'http': 'http://127.0.0.1:24000',
    'https': 'http://127.0.0.1:24000',
}

certificate_path = os.path.join(CACERT_PATH, 'cacert.pem')
key_path = os.path.join(CACERT_KEY, 'cacert.key')

resp = requests.get('https://api.myip.com',
                    proxies=proxies,
                    cert=(certificate_path, key_path))
print(resp.text)

【讨论】：

您好，谢谢您的回答。我一般不太了解 ssl 验证和证书，所以你能解释一下我在哪里可以获得这些文件以及它们是什么？提前致谢
每个操作系统都提供一组公共 CA（证书颁发机构）。当您连接到已验证但其中一个实体之一的 https 站点时，您的浏览器会告诉您该站点是安全的（相同的机制在 requests 中编码）。您收到“自签名证书”错误。自签名证书是由不在 OS 捆绑包中的 CA 签名的证书。大多数情况下，它是由内部 CA 签名的内部站点。在这种情况下，您必须向操作员询问 cacert.pem 证书和 cacert.key 密钥。否则，您将无法以安全的方式连接到该站点。
您可以在 requests 调用中添加 verify=False 以绕过此问题，但您必须了解此选择的安全隐患。

【解决方案2】：

verify=False 是一种方法，但禁用这些警告的更好方法是使用以下方法：

import urllib3

urllib3.disable_warnings()

【讨论】：

反对建议在不显示严重影响的情况下简单地忽略证书错误，即这会禁用对中间人攻击的保护。特别是因为 OP 明确要求 “这就是为什么我正在寻找更安全的解决方案”
我相信更安全意味着在任何情况下都可以使用@SteffenUllrich :)