[[330435]]

服務器上的應用服務對外發送的一些 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://support.sectigo.com/articles/Knowledge/Sectigo-AddTrust-External-CA-Root-Expiring-May-30-2020

解決方案

現在算是找到為什么請求 https 會出現證書過期的原因了。接下來看下如何解決：

1. 修改服務器ca配置
2. 更新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，感興趣的可以點擊進去看看。

https://www.gogetssl.com/news/23.html

新聞大致的意思：

由于Sectigo AddTrust外部CA根證書過期，影響了一些舊的設備或者一些老服務器，因為上面的根證書鏈中還存在該過期的 CA 證書。對于客戶端（瀏覽器/SDK）來說，他們是不受該 CA 過期的問題影響。所以最大影響是在server端. 可以通過下載最新的 AddTrust RSA 證書替換過期的。

總結

目前該問題的影響面廣不廣，這個還暫時未知，不過根據我遇到的情況來看，影響大多在服務器端的外部服務之間的調用。對web用戶端來說，因為瀏覽器內證書鏈是更新的，不涉及該問題。但對于服務端來說，對于一些對外調用的 https 請求，如果對方域名證書鏈中涉及到該過期CA的話，可能會訪問失敗。

Tips1：如果你的應用程序的部署方式是直接運行在主機上的話，可以使用配置管理工具（ansible/saltstack），統一修改。如果是容器話部署的情況，可能涉及的稍微多一些，需要修改項目的 Dockerfile，之后滾動更新該服務（當然如果你的應用不涉及到對外訪問 https/ssl 調用，理論上可以延后更改！）。

Tips2：刪除過期證書后，記得要重啟主機上運行的服務！！！