代理閘道憑證到期不只是「記住一個日期」。用戶端可能要驗證代理入口的憑證，代理也要驗證上游服務，TLS 檢查設備又會增加新的信任邊界。長連線甚至可能把錯誤部署隱藏到連線回收之後，使故障看似突然發生，實際上風險已持續數週。
這份執行手冊把憑證更新變成可重複的營運流程，適用於正向代理、HTTPS 代理入口、API 閘道、區域出口閘道及託管代理叢集。重點是讓盤點、預警、預檢、漸進發布、驗證、回復及證據保存形成閉環。
一、先畫清楚所有 TLS 邊界
依實際連線路徑盤點，而非只看架構圖。逐一記錄應用程式到代理閘道、代理經 CONNECT 到目標站、代理到控制平面或驗證服務、負載平衡器到代理節點、檢查設備到用戶端或來源站，以及健康檢查器到閘道等會終止或發起 TLS 的位置。
每個邊界至少記錄主機名稱、預期憑證簽發者、負責人、更新方式、部署對象、回復負責人，以及是否依賴 SNI。也要確認 IPv4 與 IPv6 是否落到相同憑證集；雙堆疊環境常出現一條路徑已更新、另一條仍保留舊憑證。
盤點中不要保存私鑰、權杖、代理密碼或完整工作階段資料。監控通常只需要指紋、序號、簽發者、有效期限及公開憑證鏈。
二、監控用戶端實際收到的憑證
只檢查伺服器磁碟上的憑證檔案並不可靠。應從用戶端視角探測每個生產主機名稱，涵蓋各區域、負載平衡集區、位址族與重要連接埠。收集葉憑證主體與替代名稱、完整中繼憑證鏈、UTC 格式生效與到期時間、SHA-256 指紋或序號、協商協定、使用的主機名稱與位址族，以及可取得的節點或區域標識。
探針必須使用正常信任存放區驗證憑證鏈與主機名稱。若只讀取到期時間，憑證鏈缺失或名稱不符時仍可能顯示正常。
建議設置多級門檻：到期前 45 天確認所有權、30 天確認更新已開始、14 天安排部署、7 天升級處理、24 小時進入事件應變。實際時間應依憑證壽命和變更流程調整。
三、把到期風險與部署風險分開
新憑證有效，不代表上線一定安全。部署前逐項確認：
- 存取主機名稱出現在憑證替代名稱中。
- 憑證在所有節點時鐘上已經生效。
- 必需的中繼憑證完整且順序正確。
- 不匯出私鑰即可確認公開憑證與私鑰相符。
- 金鑰類型與簽章演算法相容最舊的支援用戶端。
- 每個 SNI 名稱都會選到正確憑證。
- IPv4、IPv6、各區域與災難復原監聽器使用目標憑證套件。
- 健康檢查的主機名稱與信任路徑和實際用戶端一致。
時鐘偏差應單獨測試。若剛到憑證生效時間就部署，時鐘落後的節點可能拒絕憑證。請維持時間同步並保留安全重疊窗口。
四、在具有代表性的環境演練
測試矩陣至少包含目前用戶端、最舊支援用戶端、IPv4 與 IPv6、各驗證方式、一條 CONNECT 通道、平台支援時的一次直接 HTTPS 代理請求，以及一條長期重用連線。
演練必須回答三個問題：新連線能否完成 TLS 與驗證；代理能否建立並驗證上游連線；熱載入或替換節點時，既有連線如何變化。
也應主動模擬缺少中繼憑證、主機名稱錯誤、不受信任憑證鏈及時鐘越界，確認監控能區分原因，而非全部歸為逾時。進一步診斷可使用HTTPS 代理 TLS 疑難排解指南；若連線池影響結果，可參考代理連線池管理。
五、以重疊、金絲雀和明確回復條件上線
不要把全量替換當作第一次生產測試。依序執行：
- 把新憑證套件載入小型金絲雀集區。
- 從節點外部確認指紋與完整憑證鏈。
- 發送包含代理驗證和真實上游請求的合成流量。
- 觀察交握失敗率、連線延遲、HTTP 狀態分布、驗證錯誤及上游 TLS 錯誤。
- 依區域與位址族逐步擴大流量。
- 觀察窗口結束前保留上一份憑證套件。
- 所有監聽器和復原路徑完成驗證後才移除舊套件。
開始前先定義回復觸發條件，例如 TLS 錯誤顯著上升、新的名稱不符、憑證鏈缺失或金絲雀轉換失敗。觸發後回復憑證套件或移除故障集區，絕不能關閉憑證驗證來掩蓋問題。
六、驗證時強制建立新連線
連線重用可能產生假象。輪替前建立的 TCP/TLS 工作階段可以繼續運作，卻未看見新憑證。因此必須分別測試既有工作階段與強制新建工作階段：前者驗證平滑延續，後者確認新憑證確實被提供且受到信任。
部署後只回收一小部分連線，先從多個用戶端網路驗證新交握，再觀察正常連線池能否恢復。除非產品設計明確要求，不要同時終止整個叢集的連線。
七、以證據分類故障
- 已到期或尚未生效：檢查更新時間、節點時鐘及 SNI 實際選擇的憑證。
- 主機名稱不符：比較請求名稱、憑證替代名稱與監聽器設定。
- 未知簽發者：檢查用戶端信任存放區及目標環境是否應信任該簽發者。
- 憑證鏈不完整：檢查閘道憑證套件及所有必需中繼憑證。
- 仍提供舊憑證：尋找舊節點、備用監聽器、IPv6 路徑與負載平衡集區。
- 交握成功但代理請求失敗：分別驗證入口 TLS、代理驗證、CONNECT 政策、上游 TLS 與來源站行為。
- 只有部分用戶端失敗：比較協定版本、簽章演算法、信任庫年齡、SNI 行為及檢查政策。
所有時間使用 UTC。用戶端識別碼應雜湊或遮蔽，只保留比較節點所需的證據，不保存敏感內容。
八、關閉變更並改善下一次輪替
上線完成後再次探測所有端點，保存新指紋、簽發者、有效期限、部署時間與負責人，並確認到期警示追蹤的是線上監聽器，而非未使用的本機檔案。
檢討失敗探針、緩慢區域及手動步驟，逐步把重複檢查自動化，同時保留容易閱讀的回復說明。代理認證資料輪替可依代理認證資料輪替指南另行協調；憑證與認證資料可共用維護窗口，但兩者的失敗模式不同。
營運檢查清單
- 已盤點所有主機名稱、區域、連接埠、IPv4 與 IPv6 路徑。
- 探針從用戶端側驗證主機名稱、憑證鏈與有效期限。
- 每級到期警示均有負責人和升級路徑。
- 新憑證通過替代名稱、鏈、金鑰匹配、SNI 與相容性檢查。
- 目前及最舊支援用戶端都完成演練。
- 金絲雀流量包含驗證與真實上游請求。
- 既有連線與新建連線分別驗證。
- 回復標準與舊憑證套件均已就緒。
- 未導入任何憑證驗證繞過。
- 最終指紋與日期已記錄，且未寫入秘密資訊。
常見問題
只檢查到期時間足夠嗎？
不足。用戶端還會驗證主機名稱、信任鏈、生效時間、演算法相容性及相關政策。監控必須對公開監聽器執行正常驗證。
為什麼只有一個區域仍看到舊憑證？
常見原因是舊節點、次要負載平衡器、IPv6 監聽器、災難復原集區或長連線。請強制新建連線並記錄解析位址與憑證指紋。
輪替後要重新啟動所有代理節點嗎？
只有閘道明確要求時才需要。優先使用平滑載入、金絲雀節點和受控連線排空，以維持容量與既有工作階段穩定。
可以暫時關閉 TLS 驗證來恢復服務嗎？
這會引入新的安全與完整性風險。應回復到最後可信套件、移除錯誤節點，或修復憑證鏈及主機名稱。
合規說明
僅在獲得授權的代理基礎設施與端點上使用本流程。妥善保護私鑰與認證資料，最小化連線資料保存，遵守適用地區的隱私與安全要求，不得為了讓錯誤部署表面恢復而削弱 TLS 驗證。
