Share via

使用 應用程式閘道的相互驗證概觀

  • 發行項

相互驗證或客戶端驗證可讓 應用程式閘道 驗證傳送要求的用戶端。 通常，只有用戶端正在驗證 應用程式閘道;相互驗證可讓用戶端和 應用程式閘道 彼此驗證。

注意

我們建議使用 TLS 1.2 搭配相互驗證，因為之後會要求使用 TLS 1.2。

相互驗證

應用程式閘道 支援憑證型相互驗證，您可以在其中將受信任的用戶端 CA 憑證上傳至 應用程式閘道，而閘道會使用該憑證來驗證將要求傳送至閘道的用戶端。 隨著IoT使用案例的增加，以及跨產業的安全性需求增加，相互驗證可讓您管理和控制哪些用戶端可以與您的 應用程式閘道 通訊。

若要設定相互驗證，必須上傳受信任的用戶端 CA 憑證，作為 SSL 配置檔客戶端驗證部分的一部分。 接著，SSL 配置檔必須與接聽程式相關聯，才能完成相互驗證的設定。 您上傳的客戶端憑證中一律必須有根 CA 憑證。 您也可以上傳憑證鏈結，但除了您想要的中繼 CA 憑證之外，鏈結還必須包含跟證書。 每個上傳檔案的大小上限必須是 25 KB 或更少。

例如，如果您的用戶端憑證包含根 CA 憑證、多個中繼 CA 憑證和分葉憑證，請確定根 CA 憑證和所有中繼 CA 憑證都會上傳至一個檔案中的 應用程式閘道。 如需如何擷取受信任用戶端 CA 憑證的詳細資訊，請參閱 如何擷取受信任的用戶端 CA 憑證。

如果您要上傳具有根 CA 和中繼 CA 憑證的憑證鏈結，憑證鏈結必須以 PEM 或 CER 檔案的形式上傳至閘道。

重要

使用相互驗證時，請務必將整個受信任的用戶端 CA 憑證鏈結上傳至 應用程式閘道。

每個 SSL 配置檔最多可支援 100 個受信任的用戶端 CA 憑證鏈結。 單一 應用程式閘道 可支持總共 200 個受信任的用戶端 CA 憑證鏈結。

注意

  • 相互驗證僅適用於 Standard_v2和 WAF_v2 SKU。
  • TLS 通訊協定接聽程式的相互驗證 設定目前 可透過 REST API、PowerShell 和 CLI 取得。 即將推出 Azure 入口網站支援。

相互驗證支持的憑證

應用程式閘道 支援從公開和私人建立的證書頒發機構單位發行的憑證。

  • 從已知證書頒發機構單位簽發的 CA 憑證：在受信任的證書存儲中通常會找到中繼和跟證書，而且在裝置上幾乎沒有其他設定，可啟用信任的連線。
  • 從組織建立的證書頒發機構單位發行的 CA 憑證：這些憑證通常是透過您的組織私下發行，且不受其他實體信任。 中繼和跟證書必須匯入至信任的證書存儲，用戶端才能建立鏈結信任。

注意

從妥善建立的證書頒發機構單位發行用戶端憑證時，請考慮使用證書頒發機構單位來查看是否可以為貴組織核發中繼憑證，以防止意外的跨組織用戶端憑證驗證。

其他客戶端驗證驗證

確認客戶端憑證 DN

您可以選擇驗證客戶端憑證的立即簽發者，並且只允許 應用程式閘道 信任該簽發者。 此選項預設為關閉，但您可以透過入口網站、PowerShell 或 Azure CLI 來啟用此選項。

如果您選擇啟用 應用程式閘道 來驗證客戶端憑證的立即簽發者，以下說明如何判斷將從上傳的憑證中擷取哪些客戶端憑證簽發者 DN。

  • 案例 1： 憑證鏈結包括：跟證書 - 中繼憑證 - 分葉憑證
    • 中繼憑證的主體名稱是 應用程式閘道 會擷取為客戶端憑證簽發者 DN，並且會驗證其用途。
  • 案例 2： 憑證鏈結包括：跟證書 - intermediate1 憑證 - intermediate2 憑證 - 分葉憑證
    • Intermediate2 憑證的 主體名稱會擷取為客戶端憑證簽發者 DN，並將進行驗證。
  • 案例 3： 憑證鏈結包括：跟證書 - 分葉憑證
    • 系統會擷取跟證書的 主體名稱，並當做用戶端憑證簽發者 DN 使用。
  • 案例 4： 相同檔案中相同長度的多個憑證鏈結。 鏈結 1 包括：跟證書 - intermediate1 憑證 - 分葉憑證。 鏈結 2 包括：跟證書 - intermediate2 憑證 - 分葉憑證。
    • Intermediate1 憑證的 主體名稱將會擷取為客戶端憑證簽發者 DN。
  • 案例 5： 相同檔案中不同長度的多個憑證鏈結。 鏈結 1 包括：跟證書 - intermediate1 憑證 - 分葉憑證。 鏈結 2 包含跟證書 - intermediate2 憑證 - intermediate3 憑證 - 分葉憑證。
    • Intermediate3 憑證的 主體名稱將會擷取為客戶端憑證簽發者 DN。

重要

我們建議每個檔案只上傳一個憑證鏈結。 如果您啟用驗證客戶端憑證 DN，這特別重要。 藉由在一個檔案中上傳多個憑證鏈結，您最終會在案例 4 或 5 個案例中，並在稍後出現客戶端憑證不符合客戶端憑證簽發者 DN 應用程式閘道 從鏈結擷取時，可能會發生問題。

如需如何擷取受信任用戶端 CA 憑證鏈結的詳細資訊，請參閱 如何擷取受信任的用戶端 CA 憑證鏈結。

伺服器變數

透過相互 TLS 驗證，您可以使用其他伺服器變數，將用戶端憑證的相關信息傳遞至 應用程式閘道 後方的後端伺服器。 如需哪些伺服器變數可供使用及如何使用的詳細資訊，請參閱 伺服器變數。

證書撤銷

當用戶端起始與使用相互 TLS 驗證設定的 應用程式閘道 連線時，您不僅可以驗證憑證鏈結和簽發者的辨別名稱，還可以使用 OCSP（在線憑證狀態通訊協定）檢查用戶端憑證的撤銷狀態。 在驗證期間，用戶端所提供的憑證將會透過其授權單位資訊存取 （AIA） 延伸模組中定義的已定義 OCSP 回應程式來查閱。 如果客戶端憑證已被撤銷，應用程式閘道會以 HTTP 400 狀態代碼和原因回應用戶端。 如果憑證有效，應用程式閘道會繼續處理要求，並轉送至定義的後端集區。

您可以透過 REST API、ARM、Bicep、CLI 或 PowerShell 來啟用用戶端憑證撤銷。

若要透過 Azure PowerShell 在現有 應用程式閘道 上設定客戶端撤銷檢查，可以參考下列命令：

# Get Application Gateway configuration
$AppGw = Get-AzApplicationGateway -Name "ApplicationGateway01" -ResourceGroupName "ResourceGroup01"

# Create new SSL Profile
$profile  = Get-AzApplicationGatewaySslProfile -Name "SslProfile01" -ApplicationGateway $AppGw

# Verify Client Cert Issuer DN and enable Client Revocation Check
Set-AzApplicationGatewayClientAuthConfiguration -SslProfile $profile -VerifyClientCertIssuerDN -VerifyClientRevocation OCSP

# Update Application Gateway
Set-AzApplicationGateway -ApplicationGateway $AppGw

您可以在這裡找到 應用程式閘道 上所有適用於客戶端驗證設定的 Azure PowerShell 參考清單：

若要確認已評估用戶端要求的 OCSP 撤銷狀態， 存取記錄 會包含名為 「sslClientVerify」 的屬性，以及 OCSP 回應的狀態。

OCSP 回應程式具有高可用性，而且 應用程式閘道 與回應者之間的網路連線能力是可行的。 如果 應用程式閘道 無法解析所定義回應者的完整功能變數名稱 （FQDN），或網路連線遭到封鎖，則憑證撤銷狀態將會失敗，應用程式閘道 會傳回對要求用戶端的 400 HTTP 回應。

注意：根據先前 OCSP 回應定義的 nextUpdate 時間，透過本機快取驗證 OCSP 檢查。 如果先前的要求尚未填入 OCSP 快取，則第一個回應可能會失敗。 重試用戶端時，應該會在快取中找到回應，而且要求會如預期般處理。

備註

  • 不支援透過CRL進行撤銷檢查
  • API 2022-05-01 版引進客戶端撤銷檢查

下一步

瞭解相互驗證之後，請移至在PowerShell中使用相互驗證設定 應用程式閘道，以使用相互驗證建立 應用程式閘道。