共用方式為

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

  • 發行項

相互驗證 (或用戶端驗證) 可讓應用程式閘道驗證傳送要求的用戶端。 通常，只有用戶端會驗證應用程式閘道；相互驗證可讓用戶端和應用程式閘道彼此驗證。

注意

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

相互驗證

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

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

例如，如果您的用戶端憑證包含根憑證、多個中繼 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 中使用相互驗證設定應用程式閘道，以使用相互驗證建立應用程式閘道。