什麼是憑證關聯？

憑證關聯是一種安全性技術，其中在建立安全工作階段時，系統只會接受已授權，或稱「已關聯」的憑證。 任何使用不同憑證建立安全工作階段的嘗試，都會被拒絕。

憑證關聯歷史

憑證關聯原本是設計來防止中間人 (MITM) 攻擊的方法。 憑證關聯最早是在 2011 年因 DigiNotar 憑證授權單位 (CA) 的入侵而變得熱門，在該事件中，攻擊者成功針對包括 Google 在內的數個知名網站建立萬用字元憑證。 之後，Chrome 已更新成會「關聯」Google 網站的最新憑證，並且會拒絕呈現不同憑證的任何連線。 即使攻擊者找到讓 CA 核發詐騙憑證的方法，Chrome 仍然會將其視為無效，並拒絕連線。

雖然 Chrome 和 Firefox 等網頁瀏覽器是首批實作此技術的應用程式，其使用案例的範圍也迅速擴大。 物聯網 (IoT) 裝置、iOS 和 Android 行動應用程式，以及不同的軟體應用程式集合皆開始使用此技術來防禦中間人攻擊。

過去數年來，憑證關聯被認為是良好的安全性做法。 隨著公開受信任 CA 所採用之核發方法的透明化，也改善了對公開金鑰基礎結構 (PKI) 環境的監督。

如何處理應用程式中的憑證關聯

一般而言，應用程式包含授權憑證或憑證屬性的清單，包括主體辨別名稱、指紋、序號和公開金鑰。 應用程式可能會針對個別分葉或端實體憑證、次級 CA 憑證，甚至是根 CA 憑證進行關聯。

如果您的應用程式明確指定可接受的 CA 清單，您可能需要定期在憑證授權單位變更或過期時更新關聯的憑證。 若要偵測憑證關聯，建議您採取下列步驟：

• 如果您是應用程式開發人員，請在原始程式碼中搜尋下列任何關於 CA 變更或過期的參考。 如果有相符項目，請更新應用程式以包括遺漏的 CA。

  • 憑證指紋
  • 主體辨別名稱
  • 一般名稱
  • 序號
  • 公開金鑰
  • 其他憑證屬性

• 如果您的自訂用戶端應用程式與 Azure API 或其他 Azure 服務整合，而您不確定該應用程式是否使用憑證關聯，請洽詢應用程式廠商。

憑證關聯限制

憑證關聯的做法已變得廣為受到爭議，因為其具有不可接受的憑證靈活度成本。 其中一個特定的實作：HTTP 公開金鑰關聯 (HPKP)，已經完全淘汰

由於憑證關聯的執行方式並不存在單一 Web 標準，因此我們無法提供偵測其使用方式的直接指導方針。 雖然我們不會建議不要使用憑證關聯，但選擇使用此方法的客戶應該注意其限制。

• 確保關聯的憑證可以在短時間內更新。
• 某些產業需求 (例如 CA/Browser Forum 針對核發和管理公開信任憑證的基準要求 (英文)) 要求在特定情況下於最少 24 小時內輪替和撤銷憑證。

下一步

• 檢查 Azure 憑證授權單位詳細資料以了解即將推出的變更 (部分機器翻譯)
• 檢閱 Azure 安全性基礎最佳做法和模式 (部分機器翻譯)