【问题标题】:requests SSL: CERTIFICATE_VERIFY_FAILED with verify="./cabundle.crt"请求 SSL: CERTIFICATE_VERIFY_FAILED with verify="./cabundle.crt"
【发布时间】:2015-09-24 12:49:53
【问题描述】:

问题

简短描述:python 请求在使用自己的 cabundle 连接到服务器时不断抛出 SSL: CERTIFICATE_VERIFY_FAILED:

In [1]:  import requests
In [3]: requests.get('https://activeo.monitowl.com', verify=True)      
Out[3]: <Response [200]>
In [4]: requests.get('https://activeo.monitowl.com', verify="./ca_bundle.crt")
---------------------------------------------------------------------------
SSLError                                  Traceback (most recent call last)
<ipython-input-3-c92a3091d6ce> in <module>()
----> 1 requests.get('https://activeo.monitowl.com', verify="./ca_bundle.crt")

/home/vagrant/.virtualenvs/test/local/lib/python2.7/site-packages/requests/api.pyc in get(url, params, **kwargs)
     67 
     68     kwargs.setdefault('allow_redirects', True)
---> 69     return request('get', url, params=params, **kwargs)
     70 
     71 

/home/vagrant/.virtualenvs/test/local/lib/python2.7/site-packages/requests/api.pyc in request(method, url, **kwargs)
     48 
     49     session = sessions.Session()
---> 50     response = session.request(method=method, url=url, **kwargs)
     51     # By explicitly closing the session, we avoid leaving sockets open which
     52     # can trigger a ResourceWarning in some cases, and look like a memory leak

/home/vagrant/.virtualenvs/test/local/lib/python2.7/site-packages/requests/sessions.pyc in request(self, method, url, params, data, headers, cookies, files, auth, timeout, allow_redirects, proxies, hooks, stream, verify, cert, json)
    463         }
    464         send_kwargs.update(settings)
--> 465         resp = self.send(prep, **send_kwargs)
    466 
    467         return resp

/home/vagrant/.virtualenvs/test/local/lib/python2.7/site-packages/requests/sessions.pyc in send(self, request, **kwargs)
    571 
    572         # Send the request
--> 573         r = adapter.send(request, **kwargs)
    574 
    575         # Total elapsed time of the request (approximately)

/home/vagrant/.virtualenvs/test/local/lib/python2.7/site-packages/requests/adapters.pyc in send(self, request, stream, timeout, verify, cert, proxies)
    429         except (_SSLError, _HTTPError) as e:
    430             if isinstance(e, _SSLError):
--> 431                 raise SSLError(e, request=request)
    432             elif isinstance(e, ReadTimeoutError):
    433                 raise ReadTimeout(e, request=request)

SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

In [5]: requests.get('https://activeo.monitowl.com', verify="./ca_bundle_ff.crt")    
[same error]
In [7]:  import ssl; ssl.OPENSSL_VERSION
Out[7]: 'OpenSSL 1.0.1k 8 Jan 2015'
In [8]: import sys; print (sys.version)
2.7.9 (default, Mar  1 2015, 12:57:24) 
[GCC 4.9.2]
In [2]: requests.__version__
Out[2]: '2.7.0'

故事

我们正在使用MonitOwl 代理中的请求与 API 服务器进行通信。几天前,我们为 *.monitowl.com 订购了新证书并将其部署到新实例,我们的颁发者是 nazwa.pl。将网络浏览器指向 https://activeo.monitowl.com 工作正常,请求似乎有一些问题,设置 verify="./cabundle.crt" 时。

技术说明

在处理 ssl 的 tornado 服务器前面有一个“透明的”haproxy 检查 SNI 并重新分配流量,这是配置文件的一部分:

acl app_activeo req_ssl_sni -i activeo.monitowl.com
use_backend bk_activeo if app_activeo

我们需要提供自己的 cabundle 来控制接受的内容 - 因为安全问题和部署脚本。我们到处都在使用 debian jessie。

我已经用ssl checker 测试了服务器,除了接受旧的加密算法之外没有任何问题..

# from issuer https://panel.nazwa.pl/uploads/ssl/nazwaSSL_SHA-2.zip
$ cat monitowlcom.crt nazwasslsha2.pem certumca-ctncasha2.pem gscasha2.pem > ./ca_bundle.crt
# exported from firefox
$ cat monitowl.com nazwaSSL CertumTrustedNetworkCA CertumGlobalServicesCASHA2 > ca_bundle_ff.crt
$  openssl verify -untrusted ./ca.crt  monitowlcom.crt 
monitowlcom.crt: OK
$ c_rehash ./
$ openssl s_client -CApath ./  -connect activeo.monitowl.com:443 -servername activeo.monitowl.com
CONNECTED(00000003)
depth=4 C = PL, O = Unizeto Sp. z o.o., CN = Certum CA
verify return:1
depth=3 C = PL, O = Unizeto Technologies S.A., OU = Certum Certification Authority, CN = Certum Trusted Network CA
verify return:1
depth=2 C = PL, O = Unizeto Technologies S.A., OU = Certum Certification Authority, CN = Certum Global Services CA SHA2
verify return:1
depth=1 C = PL, O = nazwa.pl S.A., OU = http://nazwa.pl, CN = nazwaSSL
verify return:1
depth=0 C = PL, CN = *.monitowl.com, emailAddress = ***@whitehats.pl
verify return:1
[...]
*    Verify return code: 0 (ok)*

$ curl -I --cacert ca_bundle.crt https://activeo.monitowl.com 
HTTP/1.1 200 OK
$ curl -I --cacert ca_bundle_ff.crt https://activeo.monitowl.com 
HTTP/1.1 200 OK

如您所见,openssl s_client 验证连接,curl 正常工作。

在服务器端(龙卷风): SSLError: [SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:581)

我请一些朋友使用从网络浏览器导出的捆绑包进行测试,然后:

Python==2.7.9 + OpenSSL==1.0.1k => FAILS
Python==2.7.10 + OpenSSL==1.0.1k => FAILS
Python==2.7.9 + OpenSSL==1.0.1l => FAILS
Python==2.7.10 + OpenSSL==1.0.1p => WORKS
Python==2.7.10 + OpenSSL==1.0.2d => WORKS
Python==2.7.9 + OpenSSL 1.0.2d  => WORKS

我知道 python 比网络浏览器验证证书 differently,但看起来不是这里的东西。

问题

你有什么线索吗? 我还能检查什么?

这是一个错误?在 requests 中,openssl、python 还是 urllib3?

【问题讨论】:

    标签: python ssl https python-requests


    【解决方案1】:

    不要使用您的 ca 捆绑文件。尝试使用verify=True 并将证书文件的内容粘贴到 /usr/local/lib/python2.7/dist-packages/requests/cacert.pem 的底部,位置取决于您的 Linux 版本或 dist(CentOS, Debian 等)。请使用find / -name requests 定位系统中安装请求的位置,然后找出 cacert.pem。

    这是因为 Requests 默认使用这个 cacert.pem 作为自己的 ca 包。

    如果这不起作用,那么您应该获取高级颁发者证书作为证书文件。

    【讨论】:

    • 感谢您的建议,但出于安全原因,我无法使用系统/证书,只需要允许由一个(受信任的)CA 签名的证书。正如我之前指出的,verity=True 可以完美运行,但这不是我需要的。
    【解决方案2】:

    正如Lukasa(请求合作者之一)指出的那样,问题是因为python中对交叉签名链的支持很差:

    SHA256 捆绑包的问题在于,在这种情况下,“根”证书与 SHA-1 证书交叉签名,但较旧的 OpenSSL 根本不会这样。较旧的 OpenSSL 构建证书链的方式是,它从远程服务器提供的证书中构建最长的证书链,然后寻找签署该链的可信证书。如果找不到该证书,它将退出,而不检查是否可以使用其信任根构建较短的链。

    这是弃用 SHA1 根证书的一个持续问题:请参阅 certifi/python-certifi#26。不幸的是,唯一的修复方法是在您的信任库中临时使用 SHA1 根目录或升级到更新的 OpenSSL 版本。

    https://github.com/kennethreitz/requests/issues/2783

    因此,作为临时修复,我在我的 cabundle 中也包含了 SHA1 路径:

     cat ca_sha1.crt ca_sha256.crt > cabundle.crt
    

    【讨论】:

      猜你喜欢
      • 2018-11-30
      • 2019-01-17
      • 1970-01-01
      • 2020-12-07
      • 1970-01-01
      • 2015-04-01
      • 2015-05-05
      • 2021-11-10
      • 2021-02-22
      相关资源
      最近更新 更多