Question

我们使用curl作为脚本的一部分从我们的网站下载固件更新。我们网站上的链接实际上是重定向到S3存储桶上最新版本的固件。我尝试过使用带有S3 url的curl;这样可行。我们的站点是在具有两个实例的AWS EC2负载均衡器上运行的负载均衡站点。在我们的负载均衡器和NGINX托管实例上安装了GoDaddy作为发行者的CHAINED证书。以下是从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处理器的bitbaked，它带有内置的curl，以及相当大的＆＃34; mozilla + ca_certs＆＃34;在/ usr / share / ca-certificates和/etc/ca-certificates.conf中安装CA证书。这些明显有更新ca证书在bitbake上运行 - 在/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证书完全匹配。来自我们网站链中的顶级证书的SECOND与＆＃34;主题密钥标识符＆＃34;在我们的发行版中＆＃34; Go_Daddy_Root_Certificate_Authority _-_ G2.crt＆＃34; mozilla证书中的文件。但是，我们发行版中的该文件似乎并未通过＆＃34;授权密钥标识符＆＃34;链接到2类CA.链中的第三个证书在所包含的证书中根本不存在！

所以，我从链接证书的顶部取了第二个，并在我们的发行版中替换了该文件。我还将第三个证书放在分发链中，所以现在所有的GoDaddy证书都可以代表。我将它们放在/ usr / share / ca-certificates / mozilla目录中，并确保所有条目都在/etc/ca-certificates.conf文件中表示。然后我跑了＆＃34; update-ca-certificates＆＃34;

我验证了这一点，将新证书放入/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，以及那些不起作用的文章，因为盒子上没有受信任的证书数据库。直接从安全的亚马逊网址下载工作正常，但我们不想告诉客户新的网址，因此我们希望从我们的网站获得重定向。

那么，对于SSL over CURL专家，我缺少什么？

更新：curl适用于Linux Mint VM上的此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: */*
>

Answer 1

当我将其中一个负载平衡服务器的单个IP应用于mydomain.com的/ etc / hosts时，curl命令对我们的固件起作用。然后，我转到AWS上的负载均衡器，并将带有完整链的证书重新应用到负载均衡器。完成后，即使没有主机条目，curl命令也能正常工作。因此证书不正确地应用在负载均衡器上，但不知何故浏览器（以及虚拟机上功能更全面的卷曲）看到了它并获得了正确的证书，但我们固件上的版本没有。

CURL未验证证书

1 个答案: