[Linux] AddTrust External CA Root expired 處理方式 @ Ubuntu

週日也不幸踩到這個雷了，當時只解了幾個，沒想到這個範圍很大很大。

故事是我們採用 Namecheap 服務來簽署 Wildcard SSL 憑證，而使用到 AddTrust External CA Root 簽署。

當 AddTrust External CA Root 有效期間只到 2020/05/30 10:48:38 時，時間一到後，導致用戶連到我們的服務產生失敗，以 curl 來說，他預設依賴 OS 提供的系統憑證資訊：

$ curl https://ourservice.exmaple.com

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"

 of Certificate Authority (CA) public keys (CA certs). If the default

 bundle file isn't adequate, you can specify an alternate file

 using the --cacert option.

If this HTTPS server uses a certificate signed by a CA represented in

 the bundle, the certificate verification probably failed due to a

 problem with the certificate (it might be expired, or the name might

 not match the domain name in the URL).

If you'd like to turn off curl's verification of the certificate, use

 the -k (or --insecure) option.

而 Chrome Browser 很佛心，從軟體層自動幫轉到 USERTrust RSA Certification Authority。

問題的解法：

正確解法：直接再重新簽核新的憑證，新的憑證簽署時會略過已過期的項目。

臨時解法：將 https client side 的 AddTrust External CA Root 註解起來 

臨時解法，以 Ubuntu 內的 https client 為例，將 mozilla/AddTrust_External_Root.crt 那行註解起來

$ sudo vim /etc/ca-certificates.conf && sudo sh -c 'apt update && apt install ca-certificates && update-ca-certificates -f -v'

臨時解法只能解決 https client 是已知的範圍，像是服務的 client 都是自己控制的，這時就可以先解決那些 client 憑證的檢驗機制，但追到更細時，大部分的 https client 靠 OS 提供的憑證資訊就只要改一次，如果 https client 上跑 node.js 等應用，他們可能會依賴其他相關套件來維護憑證資訊，不一定會用 OS 內紀錄的憑證資訊，這時要排除會非常痛苦。因此，正確解法是重新簽發憑證