服務器上的應用服務對外發送的一些https請求都失敗了，真相竟然是。。。
問題
10點左右，同事反饋咨詢線上的Sentry服務器現在是否正常。之后去檢查Sentry服務，運行正常，但是該應用服務對接的Sentry頻道已經很久沒有事件進來了。
感覺不太對勁，再去檢查下Sentry worker專用的容器, 發現該Worker服務中中有些錯誤日志：
E, [2020-06-01T04:02:03.670850 #6] ERROR -- sentry: ** [Raven] Unable to record event with remote Sentry server (Raven::Error - SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (certificate has expired)):
/usr/local/bundle/gems/sentry-raven-2.7.3/lib/raven/transports/http.rb:34:in `rescue in send_event'
/usr/local/bundle/gems/sentry-raven-2.7.3/lib/raven/transports/http.rb:16:in `send_event'
/usr/local/bundle/gems/sentry-raven-2.7.3/lib/raven/client.rb:37:in `send_event'
/usr/local/bundle/gems/sentry-raven-2.7.3/lib/raven/instance.rb:81:in `send_event'
/App/src/worker.rb:26:in `perform'
/usr/local/bundle/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:187:in `execute_job'
/usr/local/bundle/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:169:in `block (2 levels) in process'
/usr/local/bundle/gems/sidekiq-5.1.3/lib/sidekiq/middleware/chain.rb:128:in `block in invoke'
/usr/local/bundle/gems/sentry-raven-2.7.3/lib/raven/integrations/sidekiq.rb:9:in `call'
/usr/local/bundle/gems/sidekiq-5.1.3/lib/sidekiq/middleware/chain.rb:130:in `block in invoke'
/usr/local/bundle/gems/sidekiq-5.1.3/lib/sidekiq/middleware/chain.rb:133:in `invoke'
E, [2020-06-01T04:02:03.671130 #6] ERROR -- sentry: ** [Raven] Failed to submit event: <no message value>
奇怪？sentry-worker在連sentry server 時請求域名的證書過期了？
分析
針對上面的錯誤信息，先去檢查了相關調用的域名證書的有效期，發現都在有效期內。而且印象中都是年初剛更換的。所以排除了是域名證書問題。
然后根據錯誤日志，嘗試在自己電腦上用下curl 命令,巧合的很，也遇到了類似的錯誤.
$ curl https://sentry.xxx.com
curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
我又去找了其它一臺centos主機，發現curl返回的結果是正常的，從web端和centos客戶端curl都成功的看，像是我本機電腦的curl和sentry-worker主機出了問題。
之后用到網上找到使用openssl命令排查ssl錯誤的方法:
$ openssl s_client -showcerts -servername sentry.xxx.com -connect sentry.xxx.com:443
CONNECTED(00000003)
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify error:num=10:certificate has expired
notAfter=May 30 10:48:38 2020 GMT
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=GoGetSSL Wildcard SSL/CN=*.xxx.com
i:/C=LV/L=Riga/O=GoGetSSL/CN=GoGetSSL RSA DV CA
-----BEGIN CERTIFICATE-----
#...省略
從上面執行命令返回的內容來看，這里的CA證書AddTrust External CA Root 在May 30 10:48:38 2020 GMT 這個時間過期了。
上網查了下相關的資料，發現他們官方發過一篇通告：
Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020.
解決方案
現在算是找到為什么請求https會出現證書過期的原因了。接下來看下如何解決：
- 修改服務器ca配置
- 更新ca庫信息
主機（Ubuntu）
修改服務器CA配置
修改服務器ca證書配置文件：/etc/ca-certificates.conf
sed -i "/AddTrust_External_Root.crt/d" /etc/ca-certificates.conf
更新CA庫
使用update-ca-certificates 該命令用以更新目錄/etc/ssl/certs來保存SSL證書，并生成ca-certificates.crt:
$ sudo update-ca-certificates --fresh
Clearing symlinks in /etc/ssl/certs...
done.
Updating certificates in /etc/ssl/certs...
147 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
重啟主機上的應用程序。
容器（Docker-Alpine OS）
容器同主機上的修改差不太多。修改ca配置文件，之后執行更新命令。以下以alpine系統為例：
修改配置文件：
sed -i "/AddTrust_External_Root.crt/d" /etc/ca-certificates.conf
更新ca證書鏈：
update-ca-certificates -f -v
當然上面的兩條命令最好是放在Dockerfile中，你知道，在容器里做的任何修改都是不可靠的（除非掛載了共享或卷）
Dockerfile示例，在CMD之前添加一行：
省略...
RUN sed -i "/AddTrust_External_Root.crt/d" /etc/ca-certificates.conf
&& update-ca-certificates -f -v
macOS
我自己電腦上的curl也是同樣的問題，目前沒找到好的自動修改的方式。不過找到了系統上的ca文件路徑。
先備份下文件：
sudo cp /etc/ssl/cert.pem ~/etc-ssl-cert.pem-20200601
之后，運行以下命令可以禁用掉過期的CA證書：
sudo sed -i "/^### AddTrust/,/^-.*END/ s/^/#/g" /etc/ssl/cert.pem
上面是注釋掉，當然你也可以直接編輯文件刪除這些行。
驗證
修改更新完ca配置后，再次執行curl 命令去訪問之前的網站：
$ curl https://sentry.xxx.com
這次訪問正常了.
其他問題
當時出現問題時，還有另外一個現象，就是用curl訪問其他網站（如，bing.com、qq.com）都是正常的. 懷疑是不是目標域名使用的證書鏈不一樣， 導致了只有我們業務域名出現了問題呢？
驗證下猜想
使用openssl 檢查下我們業務域名證書的鏈
# openssl s_client -connect sentry.xxx.com:443
CONNECTED(00000003)
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = LV, L = Riga, O = GoGetSSL, CN = GoGetSSL RSA DV CA
verify return:1
depth=0 OU = Domain Control Validated, OU = GoGetSSL Wildcard SSL, CN = *.xxx.com
verify return:1
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=GoGetSSL Wildcard SSL/CN=*.xxx.com
i:/C=LV/L=Riga/O=GoGetSSL/CN=GoGetSSL RSA DV CA
1 s:/C=LV/L=Riga/O=GoGetSSL/CN=GoGetSSL RSA DV CA
i:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
2 s:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
---
Server certificate
省略...
在檢測下上面說的其他網站bing.com:
$ openssl s_client -connect cn.bing.com:443
CONNECTED(00000003)
depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root
verify return:1
depth=1 C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, OU = Microsoft IT, CN = Microsoft IT TLS CA 2
verify return:1
depth=0 CN = www.bing.com
verify return:1
---
Certificate chain
0 s:/CN=www.bing.com
i:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft IT/CN=Microsoft IT TLS CA 2
1 s:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft IT/CN=Microsoft IT TLS CA 2
i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
---
省略...
我又測試了其他幾個大的站點，發現都正常。為什么唯獨我們的SSL證書鏈中的其中一個CA(Sectigo AddTrust)過期了呢？
去查找下相關的文章,關鍵詞sectigo gogetssl 2020 may 30.
發現第三條記錄中有gogetssl發布的新聞, 標題是：Sectigo AddTrust External CA Root Expired May 30, 2020, 感興趣的可以點擊進去看看。
新聞大致的意思：
由于Sectigo AddTrust外部CA根證書過期，影響了一些舊的設備或者一些老服務器，因為上面的根證書鏈中還存在該過期的CA證書。對于客戶端（瀏覽器/SDK）來說，他們是不受該CA過期的問題影響。所以最大影響是在server端. 可以通過下載最新的AddTrust RSA 證書替換過期的。
總結
目前該問題的影響面廣不廣，這個還暫時未知，不過根據我遇到的情況來看，影響大多在服務器端的外部服務之間的調用。對web用戶端來說，因為瀏覽器內證書鏈是更新的，不涉及該問題。但對于 服務端來說，對于一些對外調用的https請求，如果對方域名證書鏈中涉及到該過期CA的話，可能會訪問失敗。
Tips1：如果你的應用程序的部署方式是直接運行在主機上的話，可以使用配置管理工具（ansible/saltstack），統一修改。如果是容器話部署的情況，可能涉及的稍微多一些，需要修改項目的Dockerfile,之后滾動更新該服務（當然如果你的應用不涉及到對外訪問https/ssl調用，理論上可以延后更改！）。
Tips2: 刪除過期證書后，記得要重啟主機上運行的服務！！！
來源：
https://aliasmee.github.io/post/resolve-certificate-verify-failed-with-2020-may-30/
