应用程序网关的 TLS 终止和端到端 TLS 概述Overview of TLS termination and end to end TLS with Application Gateway

传输层安全性 (TLS)(前称为安全套接字层 (SSL))是用于在 Web 服务器与浏览器之间建立加密链接的标准安全技术。Transport Layer Security (TLS), previously known as Secure Sockets Layer (SSL), is the standard security technology for establishing an encrypted link between a web server and a browser. 该链接可确保在 Web 服务器和浏览器之间传递的所有数据都会得到保密和加密。This link ensures that all data passed between the web server and browsers remain private and encrypted. 应用程序网关支持网关上的 TLS 终止以及端到端 TLS 加密。Application gateway supports both TLS termination at the gateway as well as end to end TLS encryption.

TLS 终止TLS termination

应用程序网关支持在网关上终止 TLS,之后,流量通常会以未加密状态流到后端服务器。Application Gateway supports TLS termination at the gateway, after which traffic typically flows unencrypted to the backend servers. 在应用程序网关上执行 TLS 终止可以带来诸多优势:There are a number of advantages of doing TLS termination at the application gateway:

  • 提高性能 - 执行 TLS 解密时,初次握手最容易造成性能下降。Improved performance - The biggest performance hit when doing TLS decryption is the initial handshake. 为了提高性能,执行解密的服务器会缓存 TLS 会话 ID 并管理 TLS 会话票证。To improve performance, the server doing the decryption caches TLS session IDs and manages TLS session tickets. 如果在应用程序网关上完成此操作,则来自同一客户端的所有请求都可以使用缓存值。If this is done at the application gateway, all requests from the same client can use the cached values. 如果此操作是在后端服务器上执行的,则每当客户端的请求转到另一台服务器时,客户端都必须重新进行身份验证。If it’s done on the backend servers, then each time the client’s requests go to a different server the client must re‑authenticate. 使用 TLS 票证有助于缓解此问题,但并非所有客户端都支持 TLS 票证,并且配置和管理这些票证可能有难度。The use of TLS tickets can help mitigate this issue, but they are not supported by all clients and can be difficult to configure and manage.
  • 更好地利用后端服务器 - SSL/TLS 处理会消耗大量的 CPU 资源,随着密钥大小不断地增大,其消耗的资源会越来越多。Better utilization of the backend servers - SSL/TLS processing is very CPU intensive, and is becoming more intensive as key sizes increase. 从后端服务器中消除此任务可使它们专注于以最有效的方式提供内容。Removing this work from the backend servers allows them to focus on what they are most efficient at, delivering content.
  • 智能路由 - 解密流量后,应用程序网关便可以访问标头、URI 等请求内容,并可以使用此数据来路由请求。Intelligent routing - By decrypting the traffic, the application gateway has access to the request content, such as headers, URI, and so on, and can use this data to route requests.
  • 证书管理 - 只需在应用程序网关上购买并安装证书,所有后端服务器不需要证书。Certificate management - Certificates only need to be purchased and installed on the application gateway and not all backend servers. 这可以节省时间和开支。This saves both time and money.

若要配置 TLS 终止,需将一个 TLS/SSL 证书添加到侦听器,使应用程序网关能够根据 TLS/SSL 协议规范派生对称密钥。To configure TLS termination, a TLS/SSL certificate is required to be added to the listener to enable the Application Gateway to derive a symmetric key as per TLS/SSL protocol specification. 然后,可以使用该对称密钥来加密和解密发送到网关的流量。The symmetric key is then used to encrypt and decrypt the traffic sent to the gateway. TLS/SSL 证书需采用个人信息交换 (PFX) 格式。The TLS/SSL certificate needs to be in Personal Information Exchange (PFX) format. 此文件格式适用于导出私钥,后者是应用程序网关对流量进行加解密所必需的。This file format allows you to export the private key that is required by the application gateway to perform the encryption and decryption of traffic.

重要

侦听器上的证书要求上传整个证书链(来自 CA 的根证书、中间证书和叶证书)以建立信任链。The certificate on the listener requires the entire certificate chain to be uploaded (the root certificate from the CA, the intermediates and the leaf certificate) to establish the chain of trust.

备注

应用程序网关不提供任何用于创建新证书,或者将证书请求发送到证书颁发机构的功能。Application gateway does not provide any capability to create a new certificate or send a certificate request to a certification authority.

若要建立 TLS 连接,需要确保 TLS/SSL 证书符合以下条件:For the TLS connection to work, you need to ensure that the TLS/SSL certificate meets the following conditions:

  • 当前日期和时间处于证书上的“生效日期”和“失效日期”日期范围内。That the current date and time is within the "Valid from" and "Valid to" date range on the certificate.
  • 证书的“公用名”(CN) 与请求中的主机标头相匹配。That the certificate's "Common Name" (CN) matches the host header in the request. 例如,如果客户端正在向 https://www.contoso.com/ 发出请求,则 CN 必须是 www.contoso.comFor example, if the client is making a request to https://www.contoso.com/, then the CN must be www.contoso.com.

支持用于 TLS 终止的证书Certificates supported for TLS termination

应用程序网关支持以下类型的证书:Application gateway supports the following types of certificates:

  • CA(证书颁发机构)证书:CA 证书是证书颁发机构 (CA) 颁发的数字证书CA (Certificate Authority) certificate: A CA certificate is a digital certificate issued by a certificate authority (CA)
  • EV(扩展验证)证书:EV 证书是符合行业标准证书准则的证书。EV (Extended Validation) certificate: An EV certificate is a certificate that conforms to industry standard certificate guidelines. 使用此类证书会使浏览器地址栏变为绿色,并发布公司名称。This will turn the browser locator bar green and publish the company name as well.
  • 通配符证书:此证书支持任意数量的基于 *.site.com 的子域(其中的 * 需替换为你的子域)。Wildcard Certificate: This certificate supports any number of subdomains based on *.site.com, where your subdomain would replace the *. 但是,它不支持 site.com,因此,如果用户在不键入前导“www”的情况下访问你的网站,则通配符证书不会反映这一点。It doesn’t, however, support site.com, so in case the users are accessing your website without typing the leading "www", the wildcard certificate will not cover that.
  • 自签名证书:客户端浏览器不信任这些证书,并且会警告用户,指出虚拟服务的证书不是信任链的一部分。Self-Signed certificates: Client browsers do not trust these certificates and will warn the user that the virtual service’s certificate is not part of a trust chain. 自签名证书适合用于测试,或者管理员会在其中控制客户端并且可以安全绕过浏览器安全警报的环境。Self-signed certificates are good for testing or environments where administrators control the clients and can safely bypass the browser’s security alerts. 切勿将自签名证书用于生产工作负荷。Production workloads should never use self-signed certificates.

有关详细信息,请参阅配置应用程序网关的 TLS 终止For more information, see configure TLS termination with application gateway.

证书大小Size of the certificate

查看应用程序网关限制部分,了解支持的最大 TLS/SSL 证书大小。Check the Application Gateway limits section to know the maximum TLS/SSL certificate size supported.

端到端 TLS 加密End-to-end TLS encryption

你可能不希望与后端服务器进行未加密的通信。You may not want unencrypted communication to the backend servers. 你可能有安全要求、符合性要求,或者应用程序可能仅接受安全连接。You may have security requirements, compliance requirements, or the application may only accept a secure connection. Azure 应用程序网关通过端到端 TLS 加密来支持这些要求。Azure Application Gateway has end-to-end TLS encryption to support these requirements.

当你使用应用程序网关的第 7 层负载均衡功能时,端到端 TLS 允许你加密敏感数据并将其安全地传输到后端。End-to-end TLS allows you to encrypt and securely transmit sensitive data to the backend while you use Application Gateway's Layer-7 load-balancing features. 这些功能包括:基于 Cookie 的会话相关性、基于 URL 的路由、基于站点的路由支持、能够重写或注入 X-Forwarded-* 标头,等等。These features include cookie-based session affinity, URL-based routing, support for routing based on sites, the ability to rewrite or inject X-Forwarded-* headers, and so on.

如果配置为端到端 TLS 通信模式,应用程序网关会在网关上终止 TLS 会话,并解密用户流量。When configured with end-to-end TLS communication mode, Application Gateway terminates the TLS sessions at the gateway and decrypts user traffic. 然后,它会应用配置的规则,以选择要将流量路由到的适当后端池实例。It then applies the configured rules to select an appropriate backend pool instance to route traffic to. 应用程序网关接下来会初始化到后端服务器的新 TLS 连接,并先使用后端服务器的公钥证书重新加密数据,然后再将请求传输到后端。Application Gateway then initiates a new TLS connection to the backend server and re-encrypts data using the backend server's public key certificate before transmitting the request to the backend. 来自 Web 服务器的任何响应都会经历相同的过程返回最终用户。Any response from the web server goes through the same process back to the end user. 若要启用端到端 TLS,请将后端 HTTP 设置中的协议设置设为 HTTPS,然后再将其应用到后端池。End-to-end TLS is enabled by setting protocol setting in Backend HTTP Setting to HTTPS, which is then applied to a backend pool.

对于应用程序网关和 WAF v1 SKU,将同时向前端和后端流量应用 TLS 策略。For the Application Gateway and WAF v1 SKU, the TLS policy applies to both frontend and backend traffic. 在前端,应用程序网关充当服务器并强制实施该策略。On the front end, Application Gateway acts as the server and enforces the policy. 在后端,应用程序网关充当客户端,并在 TLS 握手期间将协议/密码信息作为首选项发送。On the backend, Application Gateway acts as the client and sends the protocol/cipher information as the preference during the TLS handshake.

对于应用程序网关和 WAF v2 SKU,仅向前端流量应用 TLS 策略,并向后端服务器提供所有密码,后端服务器可以控制在握手期间选择特定的密码和 TLS 版本。For the Application Gateway and WAF v2 SKU, the TLS policy applies only to the frontend traffic and all ciphers are offered to the backend server, which has control to select specific ciphers and TLS version during the handshake.

应用程序网关仅与符合以下条件的后端服务器通信:已将其证书加入应用程序网关的允许列表,或者其证书已由已知的 CA 颁发机构签名,并且证书的 CN 与 HTTP 后端设置中的主机名匹配。Application Gateway only communicates with those backend servers that have either allow listed their certificate with the Application Gateway or whose certificates are signed by well-known CA authorities and the certificate's CN matches the host name in the HTTP backend settings. 这些服务器包括受信任的 Azure 服务,例如 Azure 应用服务/Web 应用和 Azure API 管理。These include the trusted Azure services such as Azure App Service/Web Apps and Azure API Management.

如果后端池成员的证书未由已知 CA 颁发机构签名,则必须为后端池中已启用端到端 TLS 的每个实例配置一个证书,这样才能进行安全通信。If the certificates of the members in the backend pool are not signed by well-known CA authorities, then each instance in the backend pool with end to end TLS enabled must be configured with a certificate to allow secure communication. 添加证书后,可确保应用程序网关仅与已知后端实例通信。Adding the certificate ensures that the application gateway only communicates with known back-end instances. 从而进一步保护端到端通信。This further secures the end-to-end communication.

备注

添加到“后端 HTTP 设置”中用于对后端服务器进行身份验证的证书可以是添加到侦听器中用于在应用程序网关上实现 TLS 终止的同一个证书;为了增强安全性,也可以要求两者不同。The certificate added to Backend HTTP Setting to authenticate the backend servers can be the same as the certificate added to the listener for TLS termination at application gateway or different for enhanced security.

端到端 TLS 方案

此示例通过端到端 TLS 将使用 TLS1.2 的请求路由到 Pool1 中的后端服务器。In this example, requests using TLS1.2 are routed to backend servers in Pool1 using end to end TLS.

端到端 TLS 和证书允许列表End to end TLS and allow listing of certificates

应用程序网关只会与已知的后端实例通信,这些实例已将其证书加入应用程序网关的允许列表。Application Gateway only communicates with known backend instances that have allow listed their certificate with the application gateway. 根据所用应用程序网关版本的不同,端到端 TLS 的设置过程也存在一些差异。There are some differences in the end-to-end TLS setup process with respect to the version of Application Gateway used. 以下部分将分别对它们进行说明。The following section explains them individually.

v1 SKU 的端到端 TLSEnd-to-end TLS with the v1 SKU

若要为后端服务器启用端到端 TLS,并让应用程序网关将请求路由到后端服务器,运行状况探测必须成功并返回运行正常响应。To enable end-to-end TLS with the backend servers and for Application Gateway to route requests to them, the health probes must succeed and return healthy response.

对于 HTTPS 运行状况探测,应用程序网关 v1 SKU 使用与要上传到 HTTP 设置的身份验证证书(后端服务器证书的公钥,而不是根证书)完全匹配的证书。For HTTPS health probes, the Application Gateway v1 SKU uses an exact match of the authentication certificate (public key of the backend server certificate and not the root certificate) to be uploaded to the HTTP settings.

只允许连接到已知的和已允许的后端。Only connections to known and allowed backends are then allowed. 运行状况探测将其余后端均视为运行不正常。The remaining backends are considered unhealthy by the health probes. 自签名证书仅用于测试目的,不建议用于生产工作负荷。Self-signed certificates are for test purposes only and not recommended for production workloads. 如前面的步骤中所述,此类证书必须加入应用程序网关的允许列表,才可以使用。Such certificates must be allow listed with the application gateway as described in the preceding steps before they can be used.

备注

Azure 应用服务等受信任的 Azure 服务不需要进行身份验证和受信任的根证书设置。Authentication and trusted root certificate setup are not required for trusted Azure services such as Azure App Service. 默认情况下,它们被认为是可信的。They are considered trusted by default.

v2 SKU 的端到端 TLSEnd-to-end TLS with the v2 SKU

身份验证证书已弃用,并由应用程序网关 v2 SKU 中的受信任的根证书替换。Authentication Certificates have been deprecated and replaced by Trusted Root Certificates in the Application Gateway v2 SKU. 它们的功能与身份验证证书类似,但有一些主要区别:They function similarly to Authentication Certificates with a few key differences:

  • 由 CN 与 HTTP 后端设置中的主机名匹配的知名 CA 颁发机构签名的证书不需要任何额外的步骤即可使端到端 TLS 工作。Certificates signed by well known CA authorities whose CN matches the host name in the HTTP backend settings do not require any additional step for end to end TLS to work.

    例如,如果后端证书由知名 CA 颁发并具有 contoso.com 的 CN,并且后端 http 设置的主机字段也设置为 contoso.com,则不需要其他步骤。For example, if the backend certificates are issued by a well known CA and has a CN of contoso.com, and the backend http setting’s host field is also set to contoso.com, then no additional steps are required. 可以将后端 HTTP 设置协议设置为 HTTPS,则运行状况探测和数据路径都会启用 TLS。You can set the backend http setting protocol to HTTPS and both the health probe and data path would be TLS enabled. 如果使用 Azure 应用服务或其他 Azure Web 服务作为后端,则这些服务也是受隐式信任的,不需要对端到端 TLS 执行其他步骤。If you're using Azure App Service or other Azure web services as your backend, then these are implicitly trusted as well and no further steps are required for end to end TLS.

备注

为了使 TLS/SSL 证书受信任,后端服务器的证书必须由已知 CA 颁发。In order for a TLS/SSL certificate to be trusted, that certificate of the backend server must have been issued by a CA that is well-known. 如果证书不是由受信任的 CA 颁发的,应用程序网关会检查发证 CA 的证书是否由受信任的 CA 颁发,依此类推,直到找到受信任的 CA(此时会建立受信任的安全连接),或者直到找不到受信任的 CA(此时,应用程序网关会将后端标记为“运行不正常”)。If the certificate was not issued by a trusted CA, the application gateway will then check to see if the certificate of the issuing CA was issued by a trusted CA, and so on until either a trusted CA is found (at which point a trusted, secure connection will be established) or no trusted CA can be found (at which point the application gateway will mark the backend unhealthy). 因此,建议后端服务器证书同时包含根 CA 和中间 CA。Therefore, it is recommended the backend server certificate contain both the root and intermediate CAs.

  • 如果证书是自签名证书,或是由未知中介签名的证书,那么,要在 v2 SKU 中启用端到端 TLS,必须定义受信任的根证书。If the certificate is self-signed, or signed by unknown intermediaries, then to enable end-to-end TLS in the v2 SKU a trusted root certificate must be defined. 应用程序网关仅与符合以下条件的后端通信:其服务器证书的根证书与池关联的后端 http 设置中的受信任根证书列表之一匹配。Application Gateway only communicates with backends whose server certificate’s root certificate matches one of the list of trusted root certificates in the backend http setting associated with the pool.

  • 除了根证书匹配之外,应用程序网关 v2 还会验证后端 http 设置中指定的主机设置是否与后端服务器的 TLS/SSL 证书提供的公用名 (CN) 的主机设置相匹配。In addition to the root certificate match, Application Gateway v2 also validates if the Host setting specified in the backend http setting matches that of the common name (CN) presented by the backend server’s TLS/SSL certificate. 尝试与后端建立 TLS 连接时,应用程序网关 v2 会将服务器名称指示 (SNI) 扩展设置为后端 http 设置中指定的主机。When trying to establish a TLS connection to the backend, Application Gateway v2 sets the Server Name Indication (SNI) extension to the Host specified in the backend http setting.

  • 如果已选择“从后端目标选择主机名”,而不是选择后端 HTTP 设置中的主机字段,则 SNI 标头始终设置为后端池 FQDN,并且后端服务器 TLS/SSL 证书上的 CN 必须与其 FQDN 匹配。If pick hostname from backend target is chosen instead of the Host field in the backend http setting, then the SNI header is always set to the backend pool FQDN and the CN on the backend server TLS/SSL certificate must match its FQDN. 此方案不支持具有 IP 的后端池成员。Backend pool members with IPs aren't supported in this scenario.

  • 根证书是来自后端服务器证书的 base64 编码的根证书。The root certificate is a base64 encoded root certificate from the backend server certificates.

v1 和 v2 SKU 中的 SNI 差异SNI differences in the v1 and v2 SKU

如前所述,应用程序网关在应用程序网关侦听器处终止来自客户端的 TLS 流量(我们称其为前端连接),对流量进行解密,应用必要的规则来确定必须将请求转发到的后端服务器,并与后端服务器建立新的 TLS 会话(我们称其为后端连接)。As mentioned previously, Application Gateway terminates TLS traffic from the client at the Application Gateway Listener (let's call it the frontend connection), decrypts the traffic, applies the necessary rules to determine the backend server to which the request has to be forwarded, and establishes a new TLS session with the backend server (let's call it the backend connection).

下表概述了 v1 和 v2 SKU 在前端和后端连接方面的 SNI 差异。The following tables outline the differences in SNI between the v1 and v2 SKU in terms of frontend and backend connections.

前端 TLS 连接(客户端到应用程序网关)Frontend TLS connection (client to application gateway)


方案Scenario v1v1 v2v2
如果客户端指定了 SNI 标头,并且所有多站点侦听器都启用了“需要 SNI”标志If the client specifies SNI header and all the multi-site listeners are enabled with "Require SNI" flag 返回相应的证书;如果站点不存在(根据 server_name),则重置连接。Return the appropriate certificate and if the site doesn't exist (according to the server_name), then the connection is reset. 如果有相应的证书,则返回该证书;否则,返回配置的第一个 HTTPS 侦听器的证书(按顺序)Returns appropriate certificate if available, otherwise, returns the certificate of the first HTTPS listener configured (in the order)
如果客户端未指定 SNI 标头,并且所有多站点标头都启用了“需要 SNI”If the client doesn't specify a SNI header and if all the multi-site headers are enabled with "Require SNI" 重置连接Resets the connection 返回配置的第一个 HTTPS 侦听器的证书(按顺序)Returns the certificate of the first HTTPS listener configured (in the order)
如果客户端未指定 SNI 标头,并且有配置了证书的基本侦听器If the client doesn't specify SNI header and if there's a basic listener configured with a certificate 将基本侦听器中配置的证书返回给客户端(默认或备用证书)Returns the certificate configured in the basic listener to the client (default or fallback certificate) 返回配置的第一个 HTTPS 侦听器的证书(按顺序)Returns the certificate of the first HTTPS listener configured (in the order)

后端 TLS 连接(应用程序网关到后端服务器)Backend TLS connection (application gateway to the backend server)

对于探测流量For probe traffic


方案Scenario v1v1 v2v2
将 TLS 握手期间的 SNI (server_name) 标头设置为 FQDNSNI (server_name) header during the TLS handshake as FQDN 设置为后端池中的 FQDN。Set as FQDN from the backend pool. 根据 RFC 6066,SNI 主机名中不允许使用原义 IPv4 和 IPv6 地址。As per RFC 6066, literal IPv4 and IPv6 addresses are not permitted in SNI hostname.
注意: 后端池中的 FQDN 应通过 DNS 解析为后端服务器的 IP 地址(公共或专用)Note: FQDN in the backend pool should DNS resolve to backend server’s IP address (public or private)
将 SNI 标头 (server_name) 设置为附加到 HTTP 设置的自定义探测中的主机名(如果已配置);如果没有,则设置为 HTTP 设置中提到的主机名;如果前两项都没有,则设置为后端池中提到的 FQDN。SNI header (server_name) is set as the hostname from the custom probe attached to the HTTP settings (if configured), otherwise from the hostname mentioned in the HTTP settings, otherwise from the FQDN mentioned in the backend pool. 优先顺序为自定义探测 > HTTP 设置 > 后端池。The order of precedence is custom probe > HTTP settings > backend pool.
注意: 如果在 HTTP 设置和自定义探测中配置的主机名不同,则根据优先级,SNI 将设置为自定义探测中的主机名。Note: If the hostnames configured in HTTP settings and custom probe are different, then according to the precedence, SNI will be set as the hostname from the custom probe.
如果后端池地址是 IP 地址 (v1) 或者自定义探测主机名配置为 IP 地址 (v2)If the backend pool address is an IP address (v1) or if custom probe hostname is configured as IP address (v2) 不设置 SNI (server_name)。SNI (server_name) won’t be set.
注意: 在这种情况下,后端服务器应该能够返回默认/备用证书,并且该证书应加入 HTTP 设置中身份验证证书下的允许列表。Note: In this case, the backend server should be able to return a default/fallback certificate and this should be allow listed in HTTP settings under authentication certificate. 如果后端服务器中未配置默认/备用证书,但需要提供 SNI,则服务器可能会重置连接并导致探测失败If there’s no default/fallback certificate configured in the backend server and SNI is expected, the server might reset the connection and will lead to probe failures
按照前面提到的优先顺序,如果它们的主机名为 IP 地址,则不设置 SNI(根据 RFC 6066)。In the order of precedence mentioned previously, if they have IP address as hostname, then SNI won't be set as per RFC 6066.
注意: 如果未配置自定义探测,并且未在 HTTP 设置或后端池中设置主机名,则也不会在 v2 探测中设置 SNINote: SNI also won't be set in v2 probes if no custom probe is configured and no hostname is set on HTTP settings or backend pool

备注

如果未配置自定义探测,应用程序网关会按以下格式发送默认探测 - <protocol>://127.0.0.1:<port>/。If a custom probe is not configured, then Application Gateway sends a default probe in this format - <protocol>://127.0.0.1:<port>/. 例如,对于默认的 HTTPS 探测,它将以 https://127.0.0.1:443/ 的形式发送。For example, for a default HTTPS probe, it'll be sent as https://127.0.0.1:443/. 请注意,此处提到的 127.0.0.1 仅用作 HTTP 主机标头,而不用作 SNI 标头(根据 RFC 6066)。Note that, the 127.0.0.1 mentioned here is only used as HTTP host header and as per RFC 6066, will not be used as SNI header. 有关运行状况探测错误的详细信息,请查看后端运行状况故障排除指南For more information on health probe errors, check the backend health troubleshooting guide.

对于实时流量For live traffic


方案Scenario v1v1 v2v2
将 TLS 握手期间的 SNI (server_name) 标头设置为 FQDNSNI (server_name) header during the TLS handshake as FQDN 设置为后端池中的 FQDN。Set as FQDN from the backend pool. 根据 RFC 6066,SNI 主机名中不允许使用原义 IPv4 和 IPv6 地址。As per RFC 6066, literal IPv4 and IPv6 addresses are not permitted in SNI hostname.
注意: 后端池中的 FQDN 应通过 DNS 解析为后端服务器的 IP 地址(公共或专用)Note: FQDN in the backend pool should DNS resolve to backend server’s IP address (public or private)
将 SNI 标头 (server_name) 设置为 HTTP 设置中的主机名;如果选择了“PickHostnameFromBackendAddress”选项,或者未提及主机名,则将其设置为后端池配置中的 FQDNSNI header (server_name) is set as the hostname from the HTTP settings, otherwise, if PickHostnameFromBackendAddress option is chosen or if no hostname is mentioned, then it'll be set as the FQDN in the backend pool configuration
如果后端池地址是 IP 地址或者未在 HTTP 设置中设置主机名If the backend pool address is an IP address or hostname is not set in HTTP settings 根据 RFC 6066,如果后端池条目不是 FQDN,则不设置 SNISNI won't be set as per RFC 6066 if the backend pool entry is not an FQDN SNI 将设置为客户端的输入 FQDN 中的主机名,并且后端证书的 CN 必须与此主机名匹配。SNI will be set as the hostname from the input FQDN from the client and the backend certificate's CN has to match with this hostname.

后续步骤Next steps

了解端到端 TLS 后,请转到使用应用程序网关和 PowerShell 配置端到端 TLS,以使用端到端 TLS 创建应用程序网关。After learning about end to end TLS, go to Configure end to end TLS by using Application Gateway with PowerShell to create an application gateway using end to end TLS.