Azure 防火墙高级预览版证书Azure Firewall Premium Preview certificates

重要

Azure 防火墙高级版目前处于公共预览状态。Azure Firewall Premium is currently in public preview. 此预览版在提供时没有附带服务级别协议,不建议将其用于生产工作负荷。This preview version is provided without a service level agreement, and it's not recommended for production workloads. 某些功能可能不受支持或者受限。Certain features might not be supported or might have constrained capabilities. 有关详细信息,请参阅适用于 Azure 预览版的补充使用条款For more information, see Supplemental Terms of Use for Azure Previews.

若要正确配置 Azure 防火墙高级预览版 TLS 检查,必须提供有效的中间 CA 证书,并将其存放在 Azure Key Vault 中。To properly configure Azure Firewall Premium Preview TLS inspection, you must provide a valid intermediate CA certificate and deposit it in Azure Key vault.

Azure 防火墙高级预览版使用的证书Certificates used by Azure Firewall Premium Preview

典型部署中使用的证书有三种类型:There are three types of certificates used in a typical deployment:

  • 中间 CA 证书(CA 证书)Intermediate CA Certificate (CA Certificate)

    证书颁发机构 (CA) 是一个可签署数字证书的受信任组织。A Certificate Authority (CA) is an organization that is trusted to sign digital certificates. CA 验证申请证书的公司或个人的身份和合法性。A CA verifies identity and legitimacy of a company or individual requesting a certificate. 如果验证成功,CA 会颁发已签名的证书。If the verification is successful, the CA issues a signed certificate. 当服务器在 SSL/TLS 握手期间向客户端(例如你的 Web 浏览器)提供证书时,客户端将尝试根据已知有效签名者的列表来验证签名。When the server presents the certificate to the client (for example, your web browser) during a SSL/TLS handshake, the client attempts to verify the signature against a list of known good signers. Web 浏览器通常会附带它们完全信任的 CA 列表来识别主机。Web browsers normally come with lists of CAs that they implicitly trust to identify hosts. 如果颁发机构不在该列表中(就像一些对自己的证书进行签名的站点一样),浏览器会警告用户该证书未由公认的颁发机构签名,并询问用户是否希望继续与未经验证的站点通信。If the authority is not in the list, as with some sites that sign their own certificates, the browser alerts the user that the certificate is not signed by a recognized authority and asks the user if they wish to continue communications with unverified site.

  • 服务器证书(网站证书)Server Certificate (Website certificate)

    与特定域名相关联的证书。A certificate associated with to specific domain name. 如果网站拥有有效证书,则意味着证书颁发机构已采取措施来验证该网址确实属于该组织。If a website has a valid certificate, it means that a certificate authority has taken steps to verify that the web address actually belongs to that organization. 键入 URL 或单击指向安全网站的链接时,浏览器会检查证书是否具备以下特征:When you type a URL or follow a link to a secure website, your browser checks the certificate for the following characteristics:

    • 网站地址与证书上的地址匹配。The website address matches the address on the certificate.
    • 证书由浏览器识别为受信任颁发机构的证书颁发机构签名。The certificate is signed by a certificate authority that the browser recognizes as a trusted authority.

    偶尔,用户可能会连接到拥有不受信任证书的服务器。Occasionally users may connect to a server with an untrusted certificate. Azure 防火墙将断开连接,就像服务器终止了连接一样。Azure Firewall will drop the connection as if the server terminated the connection.

  • 根 CA 证书(根证书)Root CA Certificate (root certificate)

    证书颁发机构可以树结构形式颁发多个证书。A certificate authority can issue multiple certificates in the form of a tree structure. 根证书是这颗树的最顶层证书。A root certificate is the top-most certificate of the tree.

Azure 防火墙高级预览版可以拦截出站 HTTP/S 流量并自动为 www.website.com 生成服务器证书。Azure Firewall Premium Preview can intercept outbound HTTP/S traffic and auto-generate a server certificate for www.website.com. 此证书是使用你提供的中间 CA 证书生成的。This certificate is generated using the Intermediate CA certificate that you provide. 最终用户浏览器和客户端应用程序必须信任你的组织根 CA 证书或中间 CA 证书,此过程才会生效。End-user browser and client applications must trust your organization Root CA certificate or intermediate CA certificate for this procedure to work.

证书过程

中间 CA 证书要求Intermediate CA certificate requirements

确保 CA 证书符合以下要求:Ensure your CA certificate complies with the following requirements:

  • 作为 Key Vault 机密部署时,必须使用包含证书和私钥的无密码 PFX (Pkcs12)。When deployed as a Key Vault secret, you must use Password-less PFX (Pkcs12) with a certificate and a private key.

  • 必须是单个证书,不应包括整个证书链。It must be a single certificate, and shouldn’t include the entire chain of certificates.

  • 有效期至少为一年。It must be valid for one year forward.

  • 必须是最小大小为 4096 字节的 RSA 私钥。It must be an RSA private key with minimal size of 4096 bytes.

  • 必须使用 KeyCertSign 标志将 KeyUsage 扩展标记为“重要”(RFC 5280;4.2.1.3 密钥用法)。It must have the KeyUsage extension marked as Critical with the KeyCertSign flag (RFC 5280; 4.2.1.3 Key Usage).

  • 必须将 BasicContraints 扩展标记为“重要”(RFC 5280;4.2.1.9 基本约束)。It must have the BasicContraints extension marked as Critical (RFC 5280; 4.2.1.9 Basic Constraints).

  • CA 标志必须设为 TRUE。The CA flag must be set to TRUE.

  • 路径长度必须大于或等于 1。The Path Length must be greater than or equal to one.

Azure Key VaultAzure Key Vault

Azure Key Vault 是平台托管的机密存储,可以用来保证机密、密钥和 TLS/SSL 证书的安全。Azure Key Vault is a platform-managed secret store that you can use to safeguard secrets, keys, and TLS/SSL certificates. Azure 防火墙高级版支持与 Key Vault 集成,以获取附加到防火墙策略的服务器证书。Azure Firewall Premium supports integration with Key Vault for server certificates that are attached to a Firewall Policy.

配置密钥保管库:To configure your key vault:

  • 需要将现有证书及其密钥对导入到密钥保管库。You need to import an existing certificate with its key pair into your key vault.
  • 此外,也可使用密钥保管库机密,该机密将存储为无密码的 base-64 编码的 PFX 文件。Alternatively, you can also use a key vault secret that's stored as a password-less, base-64 encoded PFX file. PFX 文件是一个包含私钥和公钥的数字证书。A PFX file is a digital certificate containing both private key and public key.
  • 建议使用 CA 证书导入,因为这样可以根据证书到期日期来配置警报。It's recommended to use a CA certificate import because it allows you to configure an alert based on certificate expiration date.
  • 在导入证书或机密以后,需在密钥保管库中定义访问策略,以允许为标识授予对证书/机密的“获取”访问权限。After you've imported a certificate or a secret, you need to define access policies in the key vault to allow the identity to be granted get access to the certificate/secret.
  • 提供的 CA 证书需要受 Azure 工作负载信任。The provided CA certificate needs to be trusted by your Azure workload. 请确保它们已正确部署。Ensure they are deployed correctly.

你可以创建或重用现有的用户分配的托管标识,Azure 防火墙会使用该标识以你的名义从 Key Vault 检索证书。You can either create or reuse an existing user-assigned managed identity, which Azure Firewall uses to retrieve certificates from Key Vault on your behalf. 有关详细信息,请参阅什么是 Azure 资源的托管标识?For more information, see What is managed identities for Azure resources?

在策略中配置证书Configure a certificate in your policy

若要在防火墙高级策略中配置 CA 证书,请选择你的策略,然后选择“TLS 检查(预览版)”。To configure a CA certificate in your Firewall Premium policy, select your policy and then select TLS inspection (preview). 在“TLS 检查”页上选择“已启用” 。Select Enabled on the TLS inspection page. 然后在 Azure Key Vault 中选择 CA 证书,如下图所示:Then select your CA certificate in Azure Key Vault, as shown in the following figure:

Azure 防火墙高级版概览图

重要

若要从 Azure 门户查看和配置证书,必须将 Azure 用户帐户添加到 Key Vault 访问策略。To see and configure a certificate from the Azure portal, you must add your Azure user account to the Key Vault Access policy. 在“机密权限”下授予用户帐户“获取”和“列出”权限 。Give your user account Get and List under Secret Permissions. Azure Key Vault 访问策略

创建你自己的自签名 CA 证书Create your own self-signed CA certificate

为了帮助你测试和验证 TLS 检查,你可以使用以下脚本创建自己的自签名根 CA 和中间 CA。To help you test and verify TLS inspection, you can use the following scripts to create your own self-signed Root CA and Intermediate CA.

重要

在生产环境中,你应使用企业 PKI 创建中间 CA 证书。For production, you should use your corporate PKI to create an Intermediate CA certificate. 企业 PKI 利用现有的基础结构并处理向所有终结点计算机分发根 CA 的事宜。A corporate PKI leverages the existing infrastructure and handles the Root CA distribution to all endpoint machines. 有关详细信息,请参阅部署和配置 Azure 防火墙预览版的企业 CA 证书For more information, see Deploy and configure Enterprise CA certificates for Azure Firewall Preview.

此脚本有两种版本:There are two versions of this script:

  • bash 脚本 cert.sha bash script cert.sh
  • PowerShell 脚本 cert.ps1a PowerShell script cert.ps1

此外,这两个脚本都使用 openssl.cnf 配置文件。Also, both scripts use the openssl.cnf configuration file. 若要使用这些脚本,请将 openssl.cnfcert.shcert.ps1 的内容复制到本地计算机。To use the scripts, copy the contents of openssl.cnf, and cert.sh or cert.ps1 to your local computer.

脚本会生成以下文件:The scripts generate the following files:

  • rootCA.crt/rootCA.key - 根 CA 公共证书和私钥。rootCA.crt/rootCA.key - Root CA public certificate and private key.
  • interCA.crt/interCA.key - 中间 CA 公共证书和私钥interCA.crt/interCA.key - Intermediate CA public certificate and private key
  • interCA.pfx - 将由防火墙使用的中间 CA pkcs12 包interCA.pfx - Intermediate CA pkcs12 package which will be used by firewall

重要

rootCA.key 应存储在安全的脱机位置。rootCA.key should be stored in a secure offline location. 脚本会生成有效期为 1024 天的证书。The scripts generate a certificate with validity of 1024 days. 脚本要求在本地计算机上安装 openssl 二进制文件。The scripts require openssl binaries installed in your local machine. 有关详细信息,请参阅 https://www.openssl.org/For more information see https://www.openssl.org/

创建证书后,将其部署到以下位置:After the certificates are created, deploy them to the following locations:

  • rootCA.crt - 在终结点计算机上部署(仅限公共证书)。rootCA.crt - Deploy on endpoint machines (Public certificate only).
  • interCA.pfx - 在 Key Vault 上作为证书导入并分配给防火墙策略。interCA.pfx - Import as certificate on a Key Vault and assign to firewall policy.

openssl.cnfopenssl.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.shBash script - 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.ps1PowerShell - 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 "================"

故障排除Troubleshooting

如果你的 CA 证书有效,但你无法在 TLS 检查下访问 FQDN 或 URL,请检查以下各项:If your CA certificate is valid, but you can’t access FQDNs or URLs under TLS inspection, check the following items:

  • 确保 Web 服务器证书有效。Ensure the web server certificate is valid.

  • 确保在客户端操作系统上安装根 CA 证书。Ensure the Root CA certificate is installed on client operating system.

  • 确保浏览器或 HTTPS 客户端包含有效的根证书。Ensure the browser or HTTPS client contains a valid root certificate. Firefox 和其他一些浏览器可能具有特殊的认证策略。Firefox and some other browsers may have special certification policies.

  • 确保应用程序规则中的 URL 目标类型涵盖正确的路径和目标 HTML 页中嵌入的任何其他超链接。Ensure the URL destination type in your application rule covers the correct path and any other hyperlinks embedded in the destination HTML page. 可使用通配符轻松覆盖所需的完整 URL 路径。You can use wildcards for easy coverage of the entire required URL path.

后续步骤Next steps