一般我們向 SSL 註冊商申請 SSL 憑證時，通常會拿到 Key, CRT 與 CA Bundle 三個檔案。而有做過自簽憑證的人可能會好奇，一般不是只要 key + CRT 兩個檔案就夠了嗎？為什麼還要多一個 bundle 檔案呢？
這邊文章向大家介紹一下三個檔案的用途。
CRT 與 Key 檔案
SSL 用的 CRT 檔案包含了一個公鑰(Key)和一個憑證(CRT)，憑證是由信任的證書頒發機構（Certificate Authority, CA）簽署的。這個憑證確認了公鑰(Key)屬於它聲稱的實體單位（例如一個人或組織）。
CRT 是一個證書檔案，除了包含公鑰還有一些識別信息（如擁有者名稱、組織、地點等），並由一個證書頒發機構（CA）簽名。當一個瀏覽器（例如網路瀏覽器）連接到一個使用 SSL/TLS 的服務（例如 HTTPS 網站）時，服務會提供這個 .crt 檔案給客戶端。
瀏覽器使用此檔案驗證服務的身份，且會檢查這個憑證是否由它信任的 CA 簽署，並確認該憑證與服務所聲稱的身份匹配。如果檢查成功，客戶端就會信任該服務，並用該公鑰(Key)來加密與該服務之間的通信。
簡單來說，CRT 就是證書本身，包含識別訊息。Key 則是加密用的公鑰。
CA Bundle
CA bundle，也稱為證書鏈或「中繼憑證」，是一系列憑證鏈，建立了從最初的證書（如網站的 SSL 憑證）到最終信任的根憑證之間的信任路徑。如果客戶端（例如瀏覽器）可以識別並信任此鏈中的最後一個證書，則客戶端也會信任該鏈的起點憑證。
之所以需要中繼憑證，是因為憑證頒發機構（CA）通常不會直接使用其根憑證來對終端用戶的憑證進行簽名。這是因為有大量的終端用戶需要這種服務，如果直接在線上使用根憑證進行簽名，風險會過大。因此，CA 會創建一個由根憑證簽名的中間憑證（就是中繼憑證），然後用這個中間憑證來簽名用戶的憑證。
舉例來說，知名的 Let's Encrypt 機構，其現在使用的根憑證是 ISRG Root X1，而用來簽名用戶證書的則是 R3 證書。
當我們的憑證申請通過認證後，CA 會提供我們的憑證（certificate.crt）。通常，他們還會提供一個包含根憑證和中間憑證的 CA Bundle File（ca_bundle.crt）。在此情況下，certificate.crt 會包含我們的伺服器證書和中間憑證。因此，憑證鏈在我們的憑證（由中間憑證簽名）和根憑證之間建立了信任關係。
這種信任關係有助於確保網路中的安全性，尤其是在使用 HTTPS 之類的加密連接時。如果缺少 CA bundle，則客戶端可能無法驗證服務器的身份，可能導致安全問題。
要注意的是，SSL 的重點並不只有「加密」，還包含「誰加密的？」，這也就是為什麼受信任的憑證非常重要。
而在實際應用中，一個 SSL 憑證可能由一個或多個中繼證書鏈接到一個根證書，也就是層次可能會更多，不只兩層而已。這個根證書通常是由一個公認的憑證頒發機構（CA）簽發的，並且預先安裝在客戶端的操作系統或瀏覽器中。當一個客戶端接收到一個服務器的 SSL 憑證時，它會使用 CA bundle 來驗證該憑證的有效性。
缺少 CA Bundle 會怎麼樣嗎？
如果你沒有設定 CA Bundle，只有 crt 檔案會怎麼樣呢？下面是一個範例網站
https://incomplete-chain.badssl.com/
大部分的瀏覽器如 Chrome 可以正常訪問這種網站，原因是它們具有自動下載缺少的中繼證書的功能（也就是 AIA Fetching）。但是，當使用 curl 之類的工具，或是直接用 PHP 訪問該網站時，就會遇到錯誤，因為 curl 沒有自動下載中繼證書的功能。
例如，當你嘗試使用 curl 訪問這種網站時，你會看到如下的錯誤訊息：
這個錯誤訊息說明 curl 無法確定伺服器的合法性，所以無法建立安全連接。你可以參照上面提供的連結來瞭解更多關於這個問題的資訊以及如何修復它。
這種情況常常被忽視，因為人們在設定證書和用瀏覽器測試後發現一切正常就結束了，結果需要 API 存取時就被擋住。
避免經常出錯
好的工程師會盡量避免自己出現人工錯誤或 mistake，最好的辦法是讓這一切自動化。例如使用 Let's Encrypt or ZeroSSL 之類的自動化服務。如果有需要使用付費憑證，可以寫一個小工具或 script 幫助自己每個年度更新檢查SSL憑證，對網站才會有良好的保障，也讓訪客信任您的企業。
參考資源
