HTTPS 代理 TLS 憑證鏈稽核：上線前分別驗證兩層信任
一次經代理送出的 HTTPS 請求，可能包含不只一次信任判斷。使用 HTTPS 代理時，客戶端先透過 TLS 驗證代理；接著建立 CONNECT 隧道，再於隧道內獨立驗證目的站。若經核准的企業檢查閘道終止目的 TLS，客戶端看到的目的憑證還會被替換。
把這些步驟合併成「SSL 正常」一個勾選項，會掩蓋真正故障層。代理 CA 錯誤不同於目的 CA 錯誤，未知簽發者不同於憑證過期，收到成功狀態碼也不能證明預期主機、路線及回應都已驗證。
本指南用於獲准的代理部署，且始終保持對端與主機名稱驗證開啟。
先定義四種路徑
- 直連 HTTPS：客戶端到目的站只有一層 TLS。
- HTTP 代理加 CONNECT：客戶端向代理送出 CONNECT，再透過隧道建立端對端目的 TLS。
- HTTPS 代理加 CONNECT：外層 TLS 驗證代理，隧道內 TLS 獨立驗證目的站。
- 經核准的 TLS 檢查：受管中介設備終止目的 TLS，並以企業信任根簽發替代憑證。
第四種路徑不能在測試計畫中含糊寫成「透明」。它是不同的安全架構，需要明確核准、資料處理控制及受管信任散佈。
分離兩套信任設定
分別設定並指定負責人：
- 驗證 HTTPS 代理的 CA 儲存區；
- 驗證目的站的 CA 儲存區；
- 獲准為被檢查目的簽發憑證的企業 CA。
curl 使用代理專用與目的專用 CA 參數來區分兩層信任。其他執行環境也可能支援類似控制，但名稱與系統憑證庫行為會隨作業系統及 TLS 後端而不同。
受控診斷可以明確寫出兩層設定：
curl --verbose \
--proxy "$PROXY_URL" \
--proxy-cacert proxy-ca.pem \
--cacert origin-ca.pem \
"$TARGET_URL"憑證必須來自受保護的密鑰機制，不能進入命令歷程、處理程序參數或日誌。不得公開代理密碼、權杖、Cookie、私鑰及完整客戶回應。
不能用關閉驗證的參數修復正式環境故障。關閉驗證也許讓請求完成，卻同時移除本次稽核要證明的身分保證。
準備確定性憑證測試端點
只使用自有或明確獲准的目的，端點應具備：
- 有效主機名稱及憑證鏈；
- 帶已知摘要值的小型回應；
- 業務語意完成標記；
- 需要時受控的 IPv4 與 IPv6 記錄；
- 已記錄的 TLS 版本及應用層協定；
- 規劃憑證輪替的維護紀錄。
不要把無關公共網站當成唯一憑證基準。其憑證、CDN 邊緣、協定及路由都可能隨時變更。
為每層 TLS 分別蒐證
每次嘗試記錄一列去識別資料，並區分對端角色：
試驗編號
客戶端版本
TLS 後端
代理路線別名
申請市場與觀測市場
位址族
對端角色
主體名稱與 SAN 符合結果
簽發者與鏈深度
生效及到期時間
公開金鑰摘要值
TLS 版本與 ALPN 結果
SNI 名稱
驗證結果
失敗階段
回應摘要值
有效結果耗時公開金鑰摘要值適合比較觀測結果，但除非服務有正式固定政策及經過驗證的輪替流程，不要永久固定單一數值。憑證續期、金鑰輪替與 CDN 變化都可能是正常事件。
使用單變數矩陣測試
固定目的、方法、請求標頭、瀏覽器或執行環境版本及測試負載，每次只改變一個維度：
| 執行 | 路徑 | 目的 |
|---|---|---|
| A | 直連 HTTPS | 目的信任對照 |
| B | HTTP 代理加 CONNECT | 比較隧道及目的驗證 |
| C | HTTPS 代理加 CONNECT | 分離代理與目的信任 |
| D | 獲准檢查路線 | 驗證已記錄的憑證替換 |
對所需路線類型、市場與位址族重複矩陣。若包含 SOCKS5，應分開測試本機與遠端 DNS；解析路徑雖不同，目的憑證的主機名稱驗證仍必須正確。
依階段分類失敗
CONNECT 之前
檢查代理 DNS、TCP 可達性、外層 TLS、代理主機名稱驗證及代理認證。HTTPS 代理憑證錯誤屬於此階段。
CONNECT 期間
以去識別形式記錄代理回應與目標 authority。隧道遭拒、認證挑戰或連接埠不允許，不能歸類為目的 TLS 故障。
目的 TLS 期間
檢查目的 SNI、主機名稱符合、憑證鏈、有效期限、TLS 版本及 ALPN。若直連成功而所有代理路線都出現同一目的憑證錯誤，應檢查客戶端信任設定及經核准的中介設備。
TLS 之後
繼續驗證 HTTP 狀態、最終目的、回應摘要、語意完成、語言及市場。憑證可信不代表本文一定正確。
辨識非預期憑證替換
在同一測試窗口比較直連與代理結果，下列情況需要升級調查：
- 只有未經核准的檢查路線出現不同目的簽發者；
- SAN 不再符合請求主機名稱；
- 私有或企業根出現在未記錄環境；
- 憑證有效期或金鑰屬性超出政策；
- SNI 或 ALPN 無核准理由地改變；
- 憑證路徑變化同時伴隨回應摘要變化；
- 只有某個市場或出口群組呈現無法解釋的憑證鏈。
不要把每個差異自動判定為攻擊。CDN 可能提供不同但有效的鏈，憑證輪替也很正常。應結合自有測試端點、路線清單及核准信任架構判斷。
提前演練輪替與到期
在預備環境演練：目的憑證續期、目的金鑰輪替、代理憑證續期、獲准的企業中繼 CA 輪替、廢棄根移除、有效期邊界附近的時鐘偏差、舊與新 CA 套件客戶端映像，以及回復到上一個已知正常信任套件。
驗收必須同時證明「應接受」與「應拒絕」：客戶端要接受新的核准憑證鏈，也要拒絕不受信、主機名稱錯誤或已過期的測試憑證。
觀察 SNI、ALPN 與協定回退
記錄適用的每層 TLS 所協商的應用協定。不要因為直連使用 HTTP/2，就假設代理路線也一定支援。代理類型、客戶端程式庫及閘道政策都可能改變協商。
分別測量預期協定與實際協定、連線及握手時間、CONNECT 延遲、首位元組與完整回應時間、首次請求後的重用行為，以及協商失敗時的錯誤類別。協定回退可以有效，但必須可見並完成容量驗證；靜默回退可能增加連線數與尾端延遲。
區域上線門檻
Global、North America、Europe 與 APAC 只測試獲准市場。每種路線先以一個出口和低併發驗證，再逐步擴大。
上線前必須同時滿足：
- 使用 TLS 的代理對端驗證通過；
- 目的主機名稱及憑證鏈驗證通過；
- 所有憑證替換皆符合核准檢查政策；
- 觀測市場及位址族符合預期；
- 回應摘要與語意斷言通過；
- 日誌不含密鑰；
- 失敗階段可分類；
- p95 有效結果耗時在預算內；
- 回復流程已演練。
不能藉由輪替出口直到某個出口接受，來「修復」信任故障。應隔離問題路線、保留最少證據，並修復 CA、主機名稱、時鐘或閘道設定。
稽核清單
- [ ] 直連、HTTP 代理、HTTPS 代理及檢查路線命名正確。
- [ ] 代理 CA 與目的 CA 有獨立設定及負責人。
- [ ] 對端與主機名稱驗證保持開啟。
- [ ] 測試端點為自有或明確獲准。
- [ ] 代理與目的憑證證據分開保存。
- [ ] SNI、ALPN、TLS 版本及位址族已記錄。
- [ ] 憑證及中繼 CA 輪替已演練。
- [ ] 必要時涵蓋 IPv4、IPv6 及不同 DNS 模式。
- [ ] TLS 成功後繼續驗證回應完整性。
- [ ] 路線差異已與核准架構比對。
- [ ] 證據排除密鑰、私鑰及客戶負載。
- [ ] 隔離與回復流程已通過演練。
常見問題
CONNECT 是否代表代理能讀取 HTTPS 本文？
一般 CONNECT 隧道只轉送位元組，目的 TLS 仍位於客戶端與目的站之間。另行核准的 TLS 檢查閘道會終止該 TLS，因此能檢查內容。必須記錄實際架構。
為什麼 HTTPS 代理可能需要兩套 CA？
外層 TLS 驗證代理，內層 TLS 驗證目的站。它們是不同對端，應獨立驗證。
憑證指紋改變一定可疑嗎？
不一定。正常續期、金鑰輪替或 CDN 路由都可能改變指紋，應結合憑證鏈、主機名稱、時間、路線及自有端點基準調查。
能否關閉驗證來確認網路路徑？
這會移除一個故障訊號，也同時移除對端認證，可能掩蓋真正缺陷。應使用受控端點與正確 CA 設定，絕不能把不安全執行當成正式環境驗收。
合規與安全運作
只使用可信、獲准的代理與目的。TLS 檢查可能暴露敏感內容，必須遵守組織核准、隱私法律、契約限制及資料最小化政策。未經明確授權，不得攔截第三方或個人流量，也不得降低驗證來掩蓋設定錯誤。
繼續閱讀代理回應完整性測試、代理閒置逾時與長連線測試及住宅代理工作階段黏著度測試。
來源說明：IETF《RFC 9110 HTTP Semantics》，2022 年 6 月；curl 專案 SSL CA Certificates 與命令列文件，複核於 2026 年 9 月 13 日；Node.js 專案 HTTP 代理安全說明，複核於 2026 年 9 月 13 日。
