我也遇到了同样的问题。结果发现我没有在我的服务器上安装中间证书(只需将它附加到证书的底部，如下所示)。

https://www.digicert.com/ssl-support/pem-ssl-creation.htm

确保你已经安装了ca-certificates包:

sudo apt-get install ca-certificates

更新时间也可以解决这个问题:

sudo apt-get install ntpdate
sudo ntpdate -u ntp.ubuntu.com

如果您使用的是自签名证书，则可能需要手动将其添加到系统中。

我找到了一个解决类似问题的具体方法。这个想法是指向存储在系统中的cacert文件，并由另一个基于ssl的应用程序使用。

在Debian中(我不确定在其他发行版中是否相同)，证书文件(.pem)存储在/etc/ssl/certs/所以，这是为我工作的代码:

import requests
verify='/etc/ssl/certs/cacert.org.pem'
response = requests.get('https://lists.cacert.org', verify=verify)

为了猜测pem文件的选择，我已经浏览到url并检查哪个证书颁发机构(CA)生成了证书。

编辑:如果你不能编辑代码(因为你正在运行第三个应用程序)，你可以尝试直接将pem证书添加到/usr/local/lib/python2.7/dist-packages/requests/cacert。Pem(例如将其复制到文件的末尾)。

要使用的CA文件的名称可以通过验证:

cafile = 'cacert.pem' # http://curl.haxx.se/ca/cacert.pem
r = requests.get(url, verify=cafile)

如果使用verify=True，则requests使用自己的CA集，该CA集可能没有签署您的服务器证书的CA。

对我来说，原因相当微不足道。

直到几天前，我才知道SSL验证工作正常，实际上是在另一台机器上工作。

我的下一步是比较正在进行验证的机器和没有进行验证的机器之间的证书内容和大小。

这很快导致我确定在“不正确”工作的机器上的证书并不好，一旦我用“良好”证书替换它，一切都很好。

我遇到了类似或相同的认证验证问题。我读到过小于1.0.2的OpenSSL版本，请求所依赖的版本有时会在验证强证书时遇到麻烦(见这里)。CentOS 7似乎使用了1.0.1e，这似乎有问题。

我不确定如何在CentOS上解决这个问题，所以我决定允许较弱的1024bit CA证书。

import certifi # This should be already installed as a dependency of 'requests'
requests.get("https://example.com", verify=certifi.old_where())

目前请求模块中有一个问题导致此错误，出现在v2.6.2到v2.12.4 (ATOW)中:https://github.com/kennethreitz/requests/issues/2573

解决这个问题的方法是添加以下行:DEFAULT_CIPHERS = 'ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!DSS的