相关疑难解决方法(0)

我在Debian 6.0 32位服务器上配置SSL时遇到问题.我对SSL比较新,所以请耐心等待.我尽可能多地提供信息.
注意:已更改真实域名以保护服务器的标识和完整性.

组态

服务器正在使用nginx运行.它配置如下:

ssl_certificate           /usr/local/nginx/priv/mysite.ca.chained.crt;
ssl_certificate_key       /usr/local/nginx/priv/mysite.ca.key;
ssl_protocols             SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers               HIGH:!aNULL:!MD5;
ssl_verify_depth          2;

我使用此处描述的方法链接了我的证书

cat mysite.ca.crt bundle.crt > mysite.ca.chained.crt

mysite.ca.crt签名机构给我的证书在哪里,我的签字机构bundle.crt也发给我的是CA证书.问题是我没有直接从GlobalSign购买SSL证书,而是通过我的托管服务提供商Singlehop购买.

测试

证书在Safari和Chrome上正确验证,但在Firefox上验证不正确.初步搜索显示它可能是CA的问题.

我探讨了类似问题的答案,但无法找到解决方案,因为我真的不明白每个证书的用途.

我使用openssl的s_client来测试连接,并收到输出,这似乎表明与类似问题相同的问题.错误如下:

depth=0 /OU=Domain Control Validated/CN=*.mysite.ca
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /OU=Domain Control Validated/CN=*.mysite.ca
verify error:num=27:certificate not trusted
verify return:1

可以在此处找到openssl响应的完整详细信息(证书和不必要的信息被截断).

我也看到了警告:

No client certificate CA names sent

这可能是问题所在吗？如何确保nginx发送这些CA名称？

试图解决问题

我试图通过直接从GlobalSign下载根CA来解决问题,但收到了同样的错误.我使用update-ca-certificates命令在我的Debian服务器上更新了根CA ,但没有任何改变.这可能是因为从我的提供商发送的CA是正确的,因此它导致证书被链接两次,这没有帮助.

0 s:/OU=Domain …

该问题于 2020 年 3 月 31 日太平洋时间上午晚些时候开始。向 Coinbase 发出 API 调用的服务器托管在带有 node.js (GCP) 的 Google App Engine 上。与 Coinbase 相同的证书连接问题也发生在几周前，并持续了大约一天。当时证书连接问题自行消失了。无论当时还是今天，都没有对调用 Coinbase API 的服务器进行任何代码更改。相同的代码已经运行了一年多，但几个月前被转移到 App 引擎。- Coinbase 是否进行了会影响对 Google Cloud Platform 的证书身份验证的网络更改？