文章目錄
每一種客戶端在處理https的連接時都會使用不同的證書庫。IE瀏覽器和FireFox瀏覽器都可以在本瀏覽器的控制面板中找到證書管理器。在證書管理器中可以自由添加、刪除根證書。
而Linux的curl使用的證書庫在文件“/etc/pki/tls/certs/ca-bundle.crt”中。（CentOS）
以下是curl在訪問https站點時常見的報錯信息
1.Peer’s Certificate issuer is not recognized
[root@ip-172-31-32-208 nginx]# curl https://m.ipcpu.com
curl: (60) Peer’s Certificate issuer is not recognized.
More details here: http://curl.haxx.se/docs/sslcerts.html
此種情況多發生在自簽名的證書，報錯含義是簽發證書機構未經認證，無法識別。
解決辦法是將簽發該證書的私有CA公鑰cacert.pem文件內容，追加到/etc/pki/tls/certs/ca-bundle.crt。
我們在訪問12306.cn訂票網站時也報了類似的錯誤。
[root@ip-172-31-32-208 ~]# curl https://kyfw.12306.cn/
curl: (60) Peer’s certificate issuer has been marked as not trusted by the user.
More details here: http://curl.haxx.se/docs/sslcerts.html
2.SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
[root@GO-EMAIL-1 aa]# curl https://github.com/
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html
此問題多是由於本地CA證書庫過舊，導致新簽發證書無法識別。
經排查，github.com證書是由GTE CyberTrust Root簽發,現行證書時間是：
不早於(1998/8/13 0:29:00 GMT)
不晚於(2018/8/13 23:59:00 GMT)
而在我們的Redhat5.3系統中ca-bundle.crt文件發現，GTE CyberTrust Root的時間已經過期。
Issuer: C=US, O=GTE Corporation, CN=GTE CyberTrust Root
Validity
Not Before: Feb 23 23:01:00 1996 GMT
Not After : Feb 23 23:59:00 2006 GMT
解決辦法是更新本地CA證書庫。
方法一：
下載http://curl.haxx.se/ca/cacert.pem 替換/etc/pki/tls/certs/ca-bundle.crt
方法二：
使用update-ca-trust 更新CA證書庫。（CentOS6，屬於ca-certificates包）
3.unknown message digest algorithm
[root@WEB_YF_2.7 ~]#curl https://www.alipay.com
curl: (35) error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm
此問題多由證書本地openssl不能識別SSL證書籤名算法所致。www.alipay.com 使用了SHA-256 RSA 加密算法。而openssl在OpenSSL 0.9.8o才加入此算法。
解決辦法是升級本地openssl。
在我的操作系統RedHat5.3中,yum 升級openssl到openssl-0.9.8e-22.el5 就可以識別SHA-256算法。原因是Redhat每次都是給0.9.8e打補丁，而不是直接更換版本。在srpm包中我找到了這個補丁。
Summary: The OpenSSL toolkit
Name: openssl
Version: 0.9.8e
...
Patch89: openssl-fips-0.9.8e-ssl-sha256.patch
4. curl構造HTTPS請求的通用辦法
HTTPS請求不攜帶SNI
curl -k -H "Content-Type: application/x-www-form-urlencoded" -H "Host:test.hadong.com" -H "yousa1:123" --tlsv1 --cacert ca.crt --cert ./client.crt --key ./client.key -i -X GET https://10.174.230.97/release/test
HTTPS請求攜帶SNI
curl -k -H "Content-Type: application/x-www-form-urlencoded" -H "Host:test.hadong.com" -H "yousa1:123" --tlsv1 --cacert ca.crt --cert ./client.crt --key ./client.key -i -X GET https://hadong.com/release/test
上述請求中的-k是insercure的意思，即請求流程中不會對HTTPS證書合法性作校驗（通常不建議攜帶該選項，否則午飯驗證證書的合法性）
–tlsv1是使用tlsv1.0版本
-E/–cert <certificate[:password]> 爲 HTTPS/FTPS 數據包指定數字證書。數字證書必須是 PEM 格式。如果 password 沒有在內容中顯式給定，則會在連接建立時被服務器端詢問。
–key HTTPS證書的私鑰文件
–cacert FILE CA certificate to verify peer against (SSL) 證書籤發機構信息