題目與背景
CDN 邊緣節點數量多、暴露面大，直接分發長期憑證私鑰會放大失陷影響。請依據 RFC 9345 設計 Delegated Credential（DC）部署：憑證持有者簽發短期憑證，邊緣節點用憑證完成 TLS 身分驗證，但不能再簽發新的憑證。回答必須涵蓋 TLS 握手驗證、過期、輪換、撤銷邊界與回退方案。
面試官考察什麼
重點是理解 DC 與 X.509 終端憑證的繫結關係、短期私鑰的權限邊界、TLS 擴充協商、時間窗口和失陷後的影響。優秀答案會區分「縮短金鑰暴露窗口」與「即時撤銷」，並說明不支援 DC 的用戶端如何安全回退。
先問清楚的澄清問題
流量與終止位置
確認 TLS 在 CDN、區域閘道還是來源站終止，邊緣節點是否跨多個管理網域，以及是否存在 DTLS 或 QUIC 場景。不同終止位置決定簽發和分發路徑。
用戶端相容矩陣
確認瀏覽器、行動端、IoT 和內部用戶端版本，是否能升級 TLS 堆疊。DC 需要協商擴充並驗證新結構，不能假定所有用戶端自動支援。
失陷目標
確認要縮短的是長期憑證私鑰暴露範圍、邊緣節點私鑰壽命，還是二者兼顧。還要確定合規要求是否需要獨立撤銷清單或強制下線。
30 秒回答框架
「由憑證持有者簽發短期 DC，並用終端憑證公鑰驗證其簽章、用途和有效期。邊緣只拿 DC 私鑰，不能建立新的 DC；服務端按 TLS 擴充協商，用戶端驗證 DC 與憑證的繫結。用短有效期、提前重疊輪換和金鑰隔離縮小失陷窗口，同時保留長期憑證安全儲存。舊用戶端回退到普通憑證路徑，失敗時不能靜默接受未驗證憑證；失陷處置主要靠縮短壽命、停止簽發和撤銷父憑證，而非假設 DC 自帶即時撤銷。」
深入解答步驟
第一步：定義簽發關係
簽發器持有終端憑證對應的長期私鑰，產生 DC 公鑰、有效期、簽章演算法和 TLS/DTLS 使用資訊，再由終端憑證公鑰驗證簽章。邊緣只接收 DC 私鑰和公開 DC，不接觸父憑證私鑰。
第二步：限制權限與用途
DC 私鑰只能用於約定的 TLS 身分驗證，不能用於再簽發 DC。檢查憑證擴充中的 DelegationUsage、演算法相容性和傳輸協定，避免把只用於 TLS 的憑證當成通用簽章金鑰。
第三步：完成握手驗證
用戶端先驗證傳統 X.509 鏈，再驗證 DC 的簽章、有效期、父憑證繫結和握手內容。協商擴充失敗時走明確的普通憑證路徑；任何未知或不一致欄位都應導致驗證失敗，而不是忽略安全約束。
第四步：設計輪換窗口
簽發系統按邊緣時鐘偏差、傳播延遲和最大握手時長設定重疊窗口。邊緣先載入新 DC，再在舊 DC 仍有效時切換，確認分發成功後才停止舊憑證。時間同步和監控必須覆蓋臨界點。
第五步：處理洩露與撤銷
洩露 DC 私鑰的攻擊者可以在其有效期內冒充該方建立新連線，但不能簽發新的 DC。處置包括停止繼續簽發、縮短有效期、從邊緣撤下憑證，必要時撤銷父憑證或切換普通憑證；DC 本身不提供即時撤銷魔法。
第六步：相容與回退
透過用戶端矩陣和灰度流量驗證擴充支援。對不支援 DC 的用戶端使用長期憑證終止路徑，但必須保持父私鑰隔離；對「協商成功但驗證失敗」與「對端不支援」分開處理，不能把驗證失敗降級成明文或任意憑證。
第七步：觀測與演練
記錄簽發、分發、載入、握手驗證失敗、時鐘偏差和回退比例，不記錄私鑰。演練邊緣節點失陷、簽發器不可用、父憑證撤銷和全量回退，驗證在短有效期內能否完成復原。
高品質示例回答
我會把長期憑證私鑰留在簽發服務，用它簽出短期 DC；邊緣只拿 DC 私鑰。握手時先驗證 X.509 鏈，再驗證 DC 的繫結、用途、演算法、有效期和握手內容。透過重疊窗口輪換、時鐘監控、灰度相容矩陣和明確回退支援舊用戶端。DC 洩露時停止簽發、撤下邊緣憑證並等待其過期，嚴重時撤銷父憑證；監控驗證失敗和回退比例，不能把 DC 當成即時撤銷機制。
常見錯誤
- 錯誤： 認為 DC 洩露後可以像 OAuth token 一樣立即撤銷。→ 原因： RFC 設計重點是短壽命和父憑證繫結。→ 改進： 縮短有效期並準備父憑證撤銷與下線流程。
- 錯誤： 把 DC 私鑰下發給邊緣後允許邊緣繼續簽發。→ 原因： 擴大了委託鏈和權限。→ 改進： 只有受控簽發器持有父私鑰。
- 錯誤： 不支援擴充就忽略欄位繼續接受。→ 原因： 將協商相容誤當成驗證成功。→ 改進： 區分不支援、驗證失敗和普通憑證回退。
- 錯誤： 輪換只看簽發時間，不看傳播和時鐘偏差。→ 原因： 邊緣可能在憑證生效前或過期後握手。→ 改進： 設計重疊窗口並監控時間同步。
追問與回答
追問 1：DC 與普通短期 X.509 憑證有什麼區別？
DC 由現有終端憑證繫結並用於 TLS 握手，邊緣不必持有父憑證私鑰；普通短期憑證通常仍要求 CA 或憑證體系重新簽發完整憑證鏈。兩者的驗證和部署邊界不同。
追問 2：攻擊者拿到 DC 私鑰能做什麼？
攻擊者可在 DC 有效期內冒充該方建立新的 TLS 連線，但不能用它簽發新的 DC。影響窗口取決於有效期、父憑證狀態和發現處置速度。
追問 3：為什麼需要 DelegationUsage？
它限制哪些憑證明確允許參與 DC，降低把不支援委託語意的憑證帶入 DC 驗證流程的跨協定風險。
追問 4：QUIC 或 DTLS 需要另寫一套信任模型嗎？
不需要另造根信任，但必須按 RFC 9345 的協定內容和擴充驗證規則檢查用途、握手欄位與演算法，不能把 TLS 場景的解析結果未經審查複用到其他協定。