47 天有效期證書問答：您提問，Sectigo 來解答！

問題

Sectigo 的回應

Sectigo 對 Chrome 的這項提案持什麼立場？各證書頒發機構（CA）是否存在反對意見？

證書有效期縮短的趨勢，也就是「短期證書」，是一個Sectigo曾經做出過預測最早可追溯至2019年的問題。

在Sectigo，我們認同短期證書的優勢十分明確，也認可谷歌的判斷：這些調整將有助於提升整個生態系統的整體安全性。

對於無法實現自動化管理、用於AS2簽名/加密的載荷證書這類SSL/TLS證書，此次調整會產生什麼影響？

如果這些證書屬於公共根下的「SSL/TLS證書」（即伺服器認證證書），那麼它們會受到受到此次變更的影響，有效期將被縮短至47天。如果這類證書確實無法實現自動化管理，仍需透過人工流程完成證書吊銷與簽發工作。但系統管理員每年需要執行五到六次這類操作，其工作負擔不容小覷。

您是否認為，推動證書有效期縮短會給軟件供應商帶來壓力，迫使他們在自己的軟件中落地證書自動化能力（例如ACME）？

是的。谷歌「携手共進」路線圖的核心支柱之一就聚焦於自動化。具體而言，該路線圖明確了谷歌鼓勵自動化應用的方向，並強調ACME是數碼證書生命週期自動化的核心技術。

當證書進入47天有效期的自動化階段後，Sectigo相較於Let's Encrypt能提供哪些優勢？

優勢主要包括以下幾點，當中較為突出的有：

完備的證書生命週期管理（CLM）解決方案，提供圖形界面、API以及豐富的功能特性，具體包括：

• 證書發現
• 軟件代理
• 多種其他協議支援與集成能力
• 私有CA解決方案
• 統一管理視圖

此外，Sectigo還能提供Let's Encrypt（簡稱LE）不具備的技術支援與服務等級協議（SLA）。Sectigo是Let's Encrypt的支持者，但我們也清楚，許多客戶需要的不只是僅支援ACME、僅提供社區支援的服務。

如果同一張證書需要部署在多個系統和雲平台上，我們該如何操作？要怎麼實現自動化？例如我們使用了Azure Key Vault、AKS Secrets、AWS ELB/ALB等服務。

這取決於對「使用同一張證書」的具體需求。同一主體可以簽發多張證書，每個系統都可以使用對應專屬唯一密鑰的獨立證書。

這些證書的域名（SAN）及其他信息保持一致，本質上是同一張證書在各個系統中的多份副本。

但如果您的需求是在所有系統中使用完全相同的密鑰（這本身是一種不良設計選擇），則需要部署相關機制在各系統間安全傳輸密鑰材料，這種操作很難安全實現，還會提升安全風險。

什麼是CRL？

CRL是「證書吊銷列表（Certificate Revocation List）」的縮寫，是一份經過數碼簽名的證書序列號清單，列出了所有已被證書頒發機構（CA）或用戶「吊銷」（即作廢）的證書。

這一變更影響的遠不止透過網頁瀏覽器訪問的Web應用，還會對通信協議軟件產生巨大影響。許多通信類證書需要終端用戶在連接配置文件層級手動安裝，這類證書的更換需要提前30到47天通知客戶，因此即便在最理想的情況下也需要80天的準備週期。您真的認為通信軟件供應商來得及在2024年底前完成軟件改版，並推動所有客戶完成軟件升級嗎？畢竟現在還有終端用戶在使用Windows XP系統。

現實情況是，如果通信軟件供應商需要在其系統中使用公共信任的證書，他們就別無選擇，必須適配這一變更。這不是可選項，對於堅持使用老舊、不安全技術的供應商，不會設置任何豁免條款。

在不適用上述規則的場景下，私有（內部）CA會是一個可選方案，但使用私有CA需要完全掌控整個生態（包括客戶端與伺服器端），才能讓私有根數碼證書獲得信任。

我擔心的問題之一是，部分設備本身不具備自動續期的能力。如果證書有效期縮短至47天，在這類系統上管理SSL/TLS 證書將不具備可行性。目前是否有針對該問題的解決方案建議？

您說得沒錯，軟件和設備廠商需要着手開發相關功能，為證書提供API支持和更完善的自動化能力。如果廠商不做這些適配，就只能要求用戶每47天手動續期證書，或是採用一些既不實用也不穩定的變通方案、取巧手段。我們建議這類軟件廠商考慮支持ACME等開放標準。

在47天有效期的證書正式推行幾年後，證書有效期會不會進一步縮短到比如30天？

會的——等到47天有效期的機制落地、自動化得到更廣泛應用後，我們預計證書有效期還會進一步縮短。目前尚未有確切的方案公佈，但我們完全可以確定這一趨勢將會發生。

Sectigo是否提供基於自動化標準的解決方案？

是的，Sectigo Certificate Manager（SCM）為客戶構建了堅實的數碼信任基礎，可集成ACME協議及其他主流自動化協議，為短周期證書的生命週期管理提供準確、可靠的實現方式。