最近看到 Netflix 藉由 TLS 1.3 降低使用者延遲，並且由於 TLS 1.3 重新設計了交握協定 簡化的交握方式及更高的安全性，讓我想讓 Golang 同時支持 TLS 1.2 及 TLS 1.3 TLS 1.2 vs TLS 1.3 在交握上，整體差了一個往返的過程，就可以差至約 100 ms 在大量用戶的負載下，可以位伺服器降低很多資源消耗 優勢 TLS False Start 0-RTT Chiper Suite TLS 1.2 提供眾多的密碼套件可供選擇 相對的由於 TLS 1.3 不包含金鑰交換及簽章功能 測試 接下來透過 Golang 測試 TLS 1.3 支持，並基於 Golang 來測試 TLS 1.3 的速度的進步 憑證 可以透過自簽 RSA 或者 ECC 的憑證進行測試，當然正式服務還是希望可以購買付費憑證 當然最低限度就是使用 Let’s Encrypt，只是沒有受到 電子簽章法 保障，做一個簡單的比較以供參考 自簽 免費 付費 有效期限 自訂 3 個月 1 - 2 年 網站綠勾 無 有 有 賠償機制 無 無 有 用戶 個人 個人、非營利 公司、政府、重點服務 接下來回到正題，繼續自簽憑證

在處理一些憑證事務的時候，由於慣用 Chrome 進行檢查但是進行服務測試的時候 測到 Firefox 時居然出現憑證錯誤，Chrome 安全、Firefox 不安全，這也是蠻特別的，總之要解決憑證問題 從 Firefox 得到的錯誤訊息為 SEC_ERROR_UNKNOWN_ISSUER 拜了 Google 大神找到相關訊息的解釋 Firefox 什麼是「您的連線並不安全」？ SEC_ERROR_UNKNOWN_ISSUER 該憑證未受信任，因為簽發者憑證未知。 伺服器可能沒有傳送正確的中繼憑證。 您可能需要再引入另一個根憑證。 也再透過 DigiCert® SSL Installation Diagnostics Tool 第三方做一次檢查 擔心可能設定過瀏覽器的一些參數，導致憑證驗證問題，並確定 TLS Certificate is not trusted 與 Firefox 的問題是一致的 Qusetion 從透過購買的憑證，得到的憑證有 xxx.key、xxx.crt 及 ca-bundle.crt 因為我很習慣的只有使用 xxx.key 和 xxx.crt 並沒有去理會 ca-bundle.crt 看來需要使用到 ca-bundle.crt，將 bundle 包起來一起使用就沒問題了 透過以下指令將 ca-bundle.crt 及 xxx.crt 包在一起 1 cat xxx.crt ca-bundle.crt >> bundle.crt 然後使用 bundle.crt 替換 xxx.crt，並確認是否解決問題 從 Firefox 和 DigiCert® SSL Installation Diagnostics Tool 得到驗證成功