成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

一個因 CA 根證書過期引起的故障,真相竟然是…

新聞 系統運維
服務器上的應用服務對外發送的一些 https 請求都失敗了,真相竟然是……

[[330435]]

服務器上的應用服務對外發送的一些 https 請求都失敗了,真相竟然是……

問題

10點左右,同事反饋咨詢線上的Sentry 服務器現在是否正常。之后去檢查 Sentry 服務,運行正常,但是該應用服務對接的Sentry頻道已經很久沒有事件進來了。

感覺不太對勁,再去檢查下 Sentry worker專用的容器,發現該Worker服務中中有些錯誤日志:

  1. 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)): 
  2.  
  3. /usr/local/bundle/gems/sentry-raven-2.7.3/lib/raven/transports/http.rb:34:in `rescue in send_event' 
  4.  
  5. /usr/local/bundle/gems/sentry-raven-2.7.3/lib/raven/transports/http.rb:16:in `send_event' 
  6.  
  7. /usr/local/bundle/gems/sentry-raven-2.7.3/lib/raven/client.rb:37:in `send_event' 
  8.  
  9. /usr/local/bundle/gems/sentry-raven-2.7.3/lib/raven/instance.rb:81:in `send_event' 
  10.  
  11. /app/src/worker.rb:26:in `perform' 
  12.  
  13. /usr/local/bundle/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:187:in `execute_job' 
  14.  
  15. /usr/local/bundle/gems/sidekiq-5.1.3/lib/sidekiq/processor.rb:169:in `block (2 levels) in process' 
  16.  
  17. /usr/local/bundle/gems/sidekiq-5.1.3/lib/sidekiq/middleware/chain.rb:128:in `block in invoke' 
  18.  
  19. /usr/local/bundle/gems/sentry-raven-2.7.3/lib/raven/integrations/sidekiq.rb:9:in `call' 
  20.  
  21. /usr/local/bundle/gems/sidekiq-5.1.3/lib/sidekiq/middleware/chain.rb:130:in `block in invoke' 
  22.  
  23. /usr/local/bundle/gems/sidekiq-5.1.3/lib/sidekiq/middleware/chain.rb:133:in `invoke' 
  24.  
  25. E, [2020-06-01T04:02:03.671130 #6] ERROR -- sentry: ** [Raven] Failed to submit event: <no message value> 

奇怪?sentry-worker 在連sentry server 時請求域名的證書過期了?

分析

針對上面的錯誤信息,先去檢查了相關調用的域名證書的有效期,發現都在有效期內。而且印象中都是年初剛更換的。所以排除了是域名證書問題。

然后根據錯誤日志,嘗試在自己電腦上用下curl 命令,巧合的很,也遇到了類似的錯誤。

  1. $ curl https://sentry.xxx.com 
  2.  
  3. curl: (60) SSL certificate problem: certificate has expired 
  4.  
  5. More details here: https://curl.haxx.se/docs/sslcerts.html 
  6.  
  7. curl failed to verify the legitimacy of the server and therefore could not 
  8.  
  9. establish a Secure connection to it. To learn more about this situation and 
  10.  
  11. how to fix it, please visit the web page mentioned above. 

我又去找了其它一臺 Centos 主機,發現 curl 返回的結果是正常的,從 web 端和centos 客戶端 curl 都成功的看,像是我本機電腦的 curl 和sentry-worker主機出了問題。

之后用到網上找到使用openssl命令排查ssl錯誤的方法:

  1. $ openssl s_client -showcerts -servername sentry.xxx.com -connect sentry.xxx.com:443 
  2.  
  3. CONNECTED(00000003
  4.  
  5. depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root 
  6.  
  7. verify error:num=10:certificate has expired 
  8.  
  9. notAfter=May 30 10:48:38 2020 GMT 
  10.  
  11. --- 
  12.  
  13. Certificate chain 
  14.  
  15. 0 s:/OU=Domain Control Validated/OU=GoGetSSL Wildcard SSL/CN=*.xxx.com 
  16.  
  17. i:/C=LV/L=Riga/O=GoGetSSL/CN=GoGetSSL RSA DV CA 
  18.  
  19. -----BEGIN CERTIFICATE----- 
  20.  
  21. #...省略 

從上面執行命令返回的內容來看,這里的 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

  1. sed -i "/AddTrust_External_Root.crt/d" /etc/ca-certificates.conf 

更新 CA 庫

使用update-ca-certificates該命令用以更新目錄/etc/ssl/certs來保存SSL證書,并生成 ca-certificates.crt:

  1. $ sudo update-ca-certificates --fresh 
  2.  
  3. Clearing symlinks in /etc/ssl/certs... 
  4.  
  5. done. 
  6.  
  7. Updating certificates in /etc/ssl/certs... 
  8.  
  9. 147 added, 0 removed; done. 
  10.  
  11. Running hooks in /etc/ca-certificates/update.d... 
  12.  
  13. done. 

重啟主機上的應用程序。

容器(Docker-Alpine OS)

容器同主機上的修改差不太多。修改ca配置文件,之后執行更新命令。以下以alpine系統為例:

修改配置文件:

  1. sed -i "/AddTrust_External_Root.crt/d" /etc/ca-certificates.conf 

更新 ca 證書鏈:

  1. update-ca-certificates -f -v 

當然上面的兩條命令最好是放在 Dockerfile 中,你知道,在容器里做的任何修改都是不可靠的(除非掛載了共享或卷)。

Dockerfile 示例,在 CMD 之前添加一行:

省略...

  1. RUN sed -i "/AddTrust_External_Root.crt/d" /etc/ca-certificates.conf \ 
  2.  
  3. && update-ca-certificates -f -v 
  4.  
  5. MacOS 

我自己電腦上的curl也是同樣的問題,目前沒找到好的自動修改的方式。不過找到了系統上的 ca 文件路徑。

先備份下文件:

  1. sudo cp /etc/ssl/cert.pem ~/etc-ssl-cert.pem-20200601 

之后,運行以下命令可以禁用掉過期的 CA 證書:

  1. sudo sed -i "/^### AddTrust/,/^-.*END/ s/^/#/g" /etc/ssl/cert.pem 

上面是注釋掉,當然你也可以直接編輯文件刪除這些行。

驗證

修改更新完 ca 配置后,再次執行curl 命令去訪問之前的網站:

  1. $ curl https://sentry.xxx.com 

這次訪問正常了。

其他問題

當時出現問題時,還有另外一個現象,就是用 curl 訪問其他網站(如,bing.com、qq.com)都是正常的。懷疑是不是目標域名使用的證書鏈不一樣, 導致了只有我們業務域名出現了問題呢?

驗證下猜想

使用 openssl 檢查下我們業務域名證書的鏈:

  1. # openssl s_client -connect sentry.xxx.com:443 
  2.  
  3. CONNECTED(00000003
  4.  
  5. depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority 
  6.  
  7. verify return:1 
  8.  
  9. depth=1 C = LV, L = Riga, O = GoGetSSL, CN = GoGetSSL RSA DV CA 
  10.  
  11. verify return:1 
  12.  
  13. depth=0 OU = Domain Control Validated, OU = GoGetSSL Wildcard SSL, CN = *.xxx.com 
  14.  
  15. verify return:1 
  16.  
  17. --- 
  18.  
  19. Certificate chain 
  20.  
  21. 0 s:/OU=Domain Control Validated/OU=GoGetSSL Wildcard SSL/CN=*.xxx.com 
  22.  
  23. i:/C=LV/L=Riga/O=GoGetSSL/CN=GoGetSSL RSA DV CA 
  24.  
  25. 1 s:/C=LV/L=Riga/O=GoGetSSL/CN=GoGetSSL RSA DV CA 
  26.  
  27. i:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority 
  28.  
  29. 2 s:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority 
  30.  
  31. i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root 
  32.  
  33. --- 
  34.  
  35. Server certificate 
  36.  
  37. 省略... 

在檢測下上面說的其他網站 bing.com:

  1. $ openssl s_client -connect cn.bing.com:443 
  2.  
  3. CONNECTED(00000003
  4.  
  5. depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root 
  6.  
  7. verify return:1 
  8.  
  9. depth=1 C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, OU = Microsoft IT, CN = Microsoft IT TLS CA 2 
  10.  
  11. verify return:1 
  12.  
  13. depth=0 CN = www.bing.com 
  14.  
  15. verify return:1 
  16.  
  17. --- 
  18.  
  19. Certificate chain 
  20.  
  21. 0 s:/CN=www.bing.com 
  22.  
  23. i:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft IT/CN=Microsoft IT TLS CA 2 
  24.  
  25. 1 s:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft IT/CN=Microsoft IT TLS CA 2 
  26.  
  27. i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root 
  28.  
  29. --- 
  30.  
  31. 省略... 

我又測試了其他幾個大的站點,發現都正常。為什么唯獨我們的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:刪除過期證書后,記得要重啟主機上運行的服務!!!

 

責任編輯:張燕妮 來源: 高效運維
相關推薦

2023-03-13 08:09:03

Protobuffeature分割

2023-10-25 15:11:15

Java

2016-10-25 10:00:20

科技新聞早報

2020-09-29 06:45:49

JDK

2020-11-12 09:15:16

GitHubPython開發

2015-06-18 11:04:58

2020-12-15 08:05:40

路由器服務器網絡層

2021-07-28 06:51:08

Nacos代理模式

2024-08-05 01:28:26

2024-09-27 11:38:49

2021-03-04 19:29:28

程序員Unix系統

2021-10-18 13:42:52

加密貨幣金融工具

2018-07-06 00:09:47

2021-07-21 08:37:55

AI 裁判人工智能

2020-10-20 17:18:00

戴爾

2022-07-07 19:44:22

Python 3.1

2021-08-28 10:15:26

項目結構Flask

2019-03-06 12:26:42

密碼安全數據

2020-09-17 11:02:58

Go 開源技術
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 日本一区二区三区免费观看 | 91久久精品国产91久久 | 成人免费在线视频 | 伊人焦久影院 | 粉嫩av久久一区二区三区 | 欧美在线播放一区 | 九色 在线 | 国产成人精品一区二区三区网站观看 | 日韩国产中文字幕 | 在线中文字幕av | 最新一级毛片 | 国产精彩视频一区 | 韩日一区二区三区 | 精品中文字幕一区二区三区 | 91久久久久 | 国产福利视频 | 亚洲日韩中文字幕 | 久久成人激情 | 国产电影一区二区三区爱妃记 | 狠狠天天 | 91av视频在线免费观看 | 日韩欧美在线观看 | 日本精品视频在线观看 | 国产精品亚洲一区二区三区在线 | 久久成人午夜 | 日韩在线大片 | 一区二区在线免费播放 | 欧美视频成人 | 五月激情六月婷婷 | 中文字幕在线网 | 91精品国产91久久久久久 | 91精品国产综合久久久久久 | 福利视频1000 | 亚洲网站在线观看 | 91精品综合久久久久久五月天 | 高清一区二区三区 | 亚洲欧美在线视频 | 毛片免费看 | 亚洲区一区二 | 精品一区二区久久久久久久网站 | 自拍偷拍第一页 |