Ssl 卷曲未验证证书

我们使用curl作为脚本的一部分从我们的站点下载固件更新。我们网站上的链接实际上是指向S3存储桶上固件的最新版本的重定向。我已经尝试将curl与s3url一起使用；这很有效。我们的站点是在AWS EC2负载平衡器上运行的负载平衡站点，有两个实例。在我们的负载平衡器和NGINX托管实例上安装了以GoDaddy为颁发者的链式证书。下面是从Chrome上看到的链条

但是，当从我们的URL中删除固件更新时，我会收到标准证书验证错误消息

curl: (60) server certificate verification failed. CAfile: 
/etc/ssl/certs/ca-certificates.crt CRLfile: none
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"

我所尝试的：

我们的固件发行版是针对256MB闪存的ARM处理器的，它内置了curl，并且在/usr/share/ca certificates和/etc/ca-certificates.conf中安装了相当大的ca证书“mozilla+ca_certs”。这些证书显然在bitbake上运行了更新ca证书-在/etc/ssl/certs/ca-certificates.crt中有1-1匹配

我们的站点证书具有openssl解码的以下输出：

Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http://certs.godaddy.com/repository/, CN=Go Daddy Secure Certificate Authority - G2
    Validity
        Not Before: Jul  1 21:02:38 2016 GMT
        Not After : Sep 29 21:02:38 2019 GMT .......
 ......
             X509v3 Authority Key Identifier:
            keyid:40:C2:BD:27:8E:CC:34:83:30:A2:33:D7:FB:6C:B3:F0:B4:2C:80:CE

        X509v3 Subject Alternative Name:
            DNS:*.ourdomain.com
        X509v3 Subject Key Identifier:
            A2:CE:7F:D5:B2:51:2C:B1:D4:FF:34:A1:9C:B3:AF:C4:29:34:1A:FF

现在，正如您之前看到的，我们站点的证书链包括三个Go Daddy证书。我们链中四个证书的主题密钥标识符为：

root: D2:C4:B0:D2:91:D4:4C:11:71:B3:61:CB:3D:A1:FE:DD:A8:6A:D4:E3
second: 3A:9A:85:07:10:67:28:B6:EF:F6:BD:05:41:6E:20:C1:94:DA:0F:DE
third: 40:C2:BD:27:8E:CC:34:83:30:A2:33:D7:FB:6C:B3:F0:B4:2C:80:CE
OURS: A2:CE:7F:D5:B2:51:2C:B1:D4:FF:34:A1:9C:B3:AF:C4:29:34:1A:FF

链中的顶部与发行版中的Go_Daddy_Class_2_CA.crt证书完全匹配。站点链中顶部证书中的第二个与mozilla证书中发行版“Go\u Daddy\u Root\u certificate\u Authority\u-\ u G2.crt”文件中的“Subject Key Identifier”匹配。但是，我们发行版中的该文件似乎没有通过“授权密钥标识符”链接到class 2 CA。链中的第三个证书在包含的证书中根本不存在

所以，我从链式证书的顶部取了第二个，并在发行版中替换了该文件。我还将第三个证书放在发行版的链中，因此现在所有的GoDaddy证书似乎都被表示出来了。我将它们放在/usr/share/ca-certificates/mozilla目录中，并确保所有条目都表示在/etc/ca-certificates.conf文件中。然后我运行了“更新ca证书”

我对此进行了验证，将新证书放入/etc/ssl/certs/ca-certificates.crt文件中，并在运行

curl --verbose --location https://ourdomain.com/location
* found 158 certificates in /etc/ssl/certs/ca-certificates.crt
* server certificate verification failed. CAfile: /etc/ssl/certs/ca-
certificates.crt CRLfile: none
* Closing connection 0
curl: (60) server certificate verification failed.

158份证书是将我们的证书添加到组合中所必需的增加。正如我之前所说的，我已经尝试了各种方法，从直接使用--cacert，到因为盒子上没有可信的证书数据库而无效的文章。直接从安全的amazon URL下载效果很好，但我们不想告诉客户新的URL，所以我们希望从我们的网站重定向

那么，对于SSL over CURL专家来说，我缺少什么呢

更新：curl在LinuxMint虚拟机上使用与此输出完全相同的证书列表文件来处理此URL

* SSL connection using ECDHE-RSA-AES128-GCM-SHA256
* Server certificate:
*    subject: OU=Domain Control Validated; CN=*.ourdomain.com
*    start date: 2016-07-01 21:02:38 GMT
*    expire date: 2019-09-29 21:02:38 GMT
*    subjectAltName: support.ourdomain.com matched
*    issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; 
OU=http://certs.godaddy.com/repository/; CN=Go Daddy Secure Certificate 
Authority - G2
*    SSL certificate verify ok.
> GET /download/firmware HTTP/1.1
> User-Agent: curl/7.35.0
> Host: support.ourdomain.com
> Accept: */*
> 

---

当我将一个负载平衡服务器的单个IP应用到/etc/hosts for ourdomain.com时，curl命令在我们的固件上起作用。然后，我转到AWS上的负载平衡器，并将带有完整链的证书重新应用于负载平衡器。完成后，curl命令即使没有hosts条目也能工作。因此，证书在负载平衡器上应用不当，但不知何故，浏览器（以及VM上功能更全面的curl）忽略了这一点，获得了正确的证书，但我们固件上的版本没有