Azure 防火牆進階版憑證

  • 發行項

若要正確設定 Azure 防火牆進階版 TLS 檢查，您必須提供有效的中繼 CA 憑證，並將其放在 Azure Key Vault 中。

Azure 防火牆進階版所使用的憑證

一般部署中會使用三種類型的憑證：

  • 中繼 CA 憑證 (CA 憑證)

    憑證授權單位 (CA) 是受信任可簽署數位憑證的組織。 CA 會驗證要求憑證的公司或個人的身分識別和合法性。 如果驗證成功，則 CA 會發出已簽署的憑證。 伺服器在 SSL/TLS 交握期間向用戶端 (例如，您的網頁瀏覽器) 呈現憑證時，用戶端會嘗試針對「已知良好」的簽署者清單驗證簽章。 網頁瀏覽器會正常隨附其隱含信任以識別主機的 CA 清單。 如果授權單位不在清單中，則就如同簽署其專屬憑證的一些網站一樣，瀏覽器會向使用者警示有關憑證不是由辨識的授權單位所簽署，並會詢問使用者是否要繼續與未驗證的網站通訊。

  • 伺服器憑證 (網站憑證)

    與特定網域名稱相關聯的憑證。 如果網站具有有效的憑證，則表示憑證授權單位已採取步驟來確認網址是否實際屬於該組織。 當您輸入 URL 或遵循安全網站的連結時，瀏覽器會檢查憑證是否具有下列特性：

    • 網站位址符合憑證上的位址。
    • 憑證是由憑證授權單位所簽署，而瀏覽器將此憑證授權單位辨識為「受信任」授權單位。

    使用者偶而可能會使用不受信任的憑證來連線至伺服器。 Azure 防火牆將會卸除連線，就像伺服器已終止連線一樣。

  • 根 CA 憑證 (根憑證)

    憑證授權單位可以透過樹狀結構的形式發出多個憑證。 根憑證是樹狀結構的最上層憑證。

Azure 防火牆進階版可以攔截輸出 HTTP/S 流量，並自動產生 www.website.com 的伺服器憑證。 此憑證是使用您所提供的中繼 CA 憑證來產生。 終端使用者瀏覽器和用戶端應用程式 (IaaS、PaaS 和其他工作負載) 必須信任您的組織根 CA 憑證或中繼 CA 憑證，此程序才會運作。

Certificate process

中繼 CA 憑證需求

請確定 CA 憑證符合下列需求：

  • 部署為金鑰保存庫祕密時，您必須搭配使用無密碼 PFX (PKCS12) 與憑證和私密金鑰。 不支援 PEM 憑證。

  • 這必須是單一憑證，而且不應該包括整個憑證鏈結。

  • 其必須往前一年有效。

  • 其必須是大小至少為 4096 個位元組的 RSA 私密金鑰。

  • 其必須具有使用 KeyCertSign 旗標標示為「重要」的 KeyUsage 延伸模組 (RFC 5280；4.2.1.3 金鑰使用方式)。

  • 其必須具有標示為「重要」的 BasicConstraints 延伸模組 (RFC 5280；4.2.1.9 基本條件約束)。

  • CA 旗標必須設定為 TRUE。

  • 路徑長度必須大於或等於一。

  • 必須可匯出。

Azure Key Vault

Azure Key Vault 是平台管理的祕密存放區，可讓您用來保護祕密、金鑰和 TLS/SSL 憑證。 Azure 防火牆進階版支援與伺服器憑證金鑰保存庫整合，而伺服器憑證附加至防火牆原則。

若要設定金鑰保存庫：

  • 您需要將具有金鑰配對的現有憑證匯入至金鑰保存庫。
  • 或者，您也可以使用儲存為無密碼、base-64 編碼 PFX 檔案的金鑰保存庫祕密。 PFX 檔案是同時包含私密金鑰和公開金鑰的數位憑證。
  • 建議您使用 CA 憑證匯入，因為這可讓您根據憑證到期日來設定警示。
  • 匯入憑證或祕密之後，您需要在金鑰保存庫中定義存取原則，以允許要授與的身分識別取得憑證/祕密的存取權。
  • 您的 Azure 工作負載需要信任所提供的 CA 憑證。 請確定已將其正確部署。
  • 由於 Azure 防火牆進階版會列為 Key Vault 信任的服務，因此可讓您略過 Key Vault 內部防火牆，並排除任何 Key Vault 暴露在網際網路上的風險。

注意

每當您將新的防火牆 CA 憑證匯入 Azure Key Vault (無論是第一次匯入或取代過期的 CA 認證)，您應該明確以新的憑證更新 Azure 防火牆原則 TLS 設定。

您可以建立或重複使用現有使用者指派的受控身分識別，而 Azure 防火牆使用此受控身分識別來代表您從金鑰保存庫擷取憑證。 如需詳細資訊，請參閱什麼是適用於 Azure 資源的受控身分識別？

注意

目前不支援 Azure 角色型存取控制 (Azure RBAC) 進行授權。 請改用存取原則模型。 如需詳細資訊，請參閱 Azure 角色型存取控制 (Azure RBAC) 與存取原則。

在您的原則中設定憑證

若要在防火牆進階版原則中設定 CA 憑證，請選取您的原則，然後選取 [TLS 檢查]。 選取 [TLS 檢查] 頁面上的 [已啟用]。 然後在 Azure Key Vault 中選取您的 CA 憑證，如下圖所示：

Azure Firewall Premium overview diagram

重要

若要查看並設定來自 Azure 入口網站的憑證，您必須將 Azure 使用者帳戶新增至金鑰保存庫存取原則。 在 [祕密權限] 下，提供使用者帳戶的 Get 和 List。 Azure Key Vault Access policy

建立您自己的自我簽署 CA 憑證

如果您想要建立自己的憑證來協助您測試和驗證 TLS 檢查，則可以使用下列指令碼來建立自己的自我簽署根 CA 和中繼 CA。

重要

針對生產環境，您應該使用公司 PKI 來建立中繼 CA 憑證。 公司 PKI 會利用現有基礎結構，並處理根 CA 到所有端點機器的散發。 如需詳細資訊，請參閱針對 Azure 防火牆部署和設定 Enterprise CA 憑證。

此指令碼有兩個版本：

  • Bash 指令碼 cert.sh
  • PowerShell 指令碼 cert.ps1

此外，這兩個指令碼都會使用 openssl.cnf 設定檔。 若要使用這些指令碼，請將 openssl.cnf 和 cert.sh 或 cert.ps1 的內容複製至本機電腦。

這些指令碼會產生下列檔案：

  • rootCA.crt/rootCA.key - 根 CA 公開憑證和私密金鑰。
  • interCA.crt/interCA.key - 中繼 CA 公開憑證和私密金鑰
  • interCA.pfx - 防火牆將使用的中繼 CA pkcs12 套件

重要

rootCA.key 應該儲存在安全的離線位置。 這些指令碼會產生有效期為 1024 天的憑證。 這些指令碼需要在本機機器中安裝 openssl 二進位檔。 如需詳細資訊，請參閱 https://www.openssl.org/

建立憑證之後，請將其部署至下列位置：

  • rootCA.crt - 在端點機器上部署 (僅限公用憑證)。
  • interCA.pfx - 匯入為金鑰保存庫上的憑證，並指派給防火牆原則。

openssl.cnf

[ req ]
default_bits        = 4096
distinguished_name  = req_distinguished_name
string_mask         = utf8only
default_md          = sha512

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code)
stateOrProvinceName             = State or Province Name
localityName                    = Locality Name
0.organizationName              = Organization Name
organizationalUnitName          = Organizational Unit Name
commonName                      = Common Name
emailAddress                    = Email Address

[ rootCA_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ interCA_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:1
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ server_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:false
keyUsage = critical, digitalSignature
extendedKeyUsage = serverAuth

Bash 指令碼 - cert.sh

#!/bin/bash

# Create root CA
openssl req -x509 -new -nodes -newkey rsa:4096 -keyout rootCA.key -sha256 -days 1024 -out rootCA.crt -subj "/C=US/ST=US/O=Self Signed/CN=Self Signed Root CA" -config openssl.cnf -extensions rootCA_ext

# Create intermediate CA request
openssl req -new -nodes -newkey rsa:4096 -keyout interCA.key -sha256 -out interCA.csr -subj "/C=US/ST=US/O=Self Signed/CN=Self Signed Intermediate CA"

# Sign on the intermediate CA
openssl x509 -req -in interCA.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out interCA.crt -days 1024 -sha256 -extfile openssl.cnf -extensions interCA_ext

# Export the intermediate CA into PFX
openssl pkcs12 -export -out interCA.pfx -inkey interCA.key -in interCA.crt -password "pass:"

echo ""
echo "================"
echo "Successfully generated root and intermediate CA certificates"
echo "   - rootCA.crt/rootCA.key - Root CA public certificate and private key"
echo "   - interCA.crt/interCA.key - Intermediate CA public certificate and private key"
echo "   - interCA.pfx - Intermediate CA pkcs12 package which could be uploaded to Key Vault"
echo "================"

PowerShell - cert.ps1

# Create root CA
openssl req -x509 -new -nodes -newkey rsa:4096 -keyout rootCA.key -sha256 -days 3650 -out rootCA.crt -subj '/C=US/ST=US/O=Self Signed/CN=Self Signed Root CA' -config openssl.cnf -extensions rootCA_ext

# Create intermediate CA request
openssl req -new -nodes -newkey rsa:4096 -keyout interCA.key -sha256 -out interCA.csr -subj '/C=US/ST=US/O=Self Signed/CN=Self Signed Intermediate CA'

# Sign on the intermediate CA
openssl x509 -req -in interCA.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out interCA.crt -days 3650 -sha256 -extfile openssl.cnf -extensions interCA_ext

# Export the intermediate CA into PFX
openssl pkcs12 -export -out interCA.pfx -inkey interCA.key -in interCA.crt -password 'pass:'

Write-Host ""
Write-Host "================"
Write-Host "Successfully generated root and intermediate CA certificates"
Write-Host "   - rootCA.crt/rootCA.key - Root CA public certificate and private key"
Write-Host "   - interCA.crt/interCA.key - Intermediate CA public certificate and private key"
Write-Host "   - interCA.pfx - Intermediate CA pkcs12 package which could be uploaded to Key Vault"
Write-Host "================"

憑證自動產生

針對非生產部署，您可以使用 Azure 防火牆進階版認證自動產生機制，而此機制會自動為您建立下列三個資源：

  • 受控識別
  • Key Vault
  • 自我簽署根 CA 憑證

只要選擇新的受控身分識別，它便會在進階版原則中將三個資源繫結在一起，並設定 TLS 檢查。

Screenshot showing auto-generated certificates.

疑難排解

如果 CA 憑證有效，但您無法透過 TLS 檢查來存取 FQDN 或 URL，則請檢查下列各項目：

  • 確定網頁伺服器憑證有效。

  • 確定已在用戶端作業系統上安裝根 CA 憑證。

  • 確定瀏覽器或 HTTPS 用戶端包含有效的根憑證。 Firefox 和一些其他瀏覽器可能會有特殊認證原則。

  • 確定應用程式規則中的 URL 目的地類型涵蓋正確路徑，以及目的地 HTML 頁面中內嵌的任何其他超連結。 您可以使用萬用字元輕鬆地涵蓋整個所需 URL 路徑。

下一步