请求SSL: CERTIFICATE_VERIFY_FAILED with verify="./cabundle.crt“
问题
简短描述: python请求在用自己的线轴连接到服务器时不断抛出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。将when浏览器指向https://activeo.monitowl.com工作得完美无缺，当设置verify="./cabundle.crt“时，请求似乎有一些问题。
技术说明
在处理ssl的龙卷风服务器前面，有一个“透明的”haproxy检查SNI并重新分发流量，这是配置文件的一部分：
acl app_activeo req_ssl_sni -i activeo.monitowl.com
use_backend bk_activeo if app_activeo由于安全问题和部署脚本，我们需要提供自己的计程车来控制所接受的内容。我们到处都在用debian jessie。
我已经用ssl检查器对服务器进行了测试，除了接受旧的密码算法之外，没有任何问题。
# 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)
我让一些朋友用从web浏览器导出的包来测试它，并且：
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比web浏览器更能验证certs 不同的，但是这里似乎不是这样的。
问题
你有什么线索吗?这包有什么问题？我还能查到什么？
是个窃听器？在请求中，openssl、python还是urllib3？
回答 2
Stack Overflow用户
发布于 2015-10-01 08:21:00
正如卢卡萨 (请求协作者之一)所指出的，问题在于python中对交叉签名链的支持很差：
SHA256包的问题是，在这种情况下，'root‘证书是与SHA-1证书交叉签名的，但是老版本的OpenSSL根本就不会这样。较早的OpenSSL构建证书链的方式是，它从远程服务器提供的证书中构建最长的证书，然后查找签名该链的可信证书。如果它找不到该证书，它就会退出，而不检查它是否可以使用它的信任根构建一个更短的链。 这是一个持续存在的SHA1根证书废弃问题:请参阅证书/python-证书#26。不幸的是，唯一的修复方法是暂时使用信任存储中的SHA1根，或者升级到更新的OpenSSL版本。
https://github.com/kennethreitz/requests/issues/2783
因此，作为临时修复，我也将SHA1路径包括在我的驾驶室中：
cat ca_sha1.crt ca_sha256.crt > cabundle.crtStack Overflow用户
发布于 2015-10-01 03:25:37
不要使用您的ca包文件。尝试使用/usr/local/lib/python2.7/dist-packages/requests/cacert.pem，文件的verify=True并将内容粘贴到verify=True的底部，位置取决于您的Linux或dist (CentOS、Debian等)。请使用find / -name requests定位系统中的请求安装位置，然后查找cacert.pem。
这是因为请求默认使用此cacert.pem作为自己的ca包。
如果这不起作用，那么您应该将高级别的颁发者证书作为证书文件。
https://stackoverflow.com/questions/32761774
复制相似问题
腾讯云开发者
