應用程式閘道的 TLS 終止和端對端 TLS 概觀Overview of TLS termination and end to end TLS with Application Gateway

傳輸層安全性 (TLS) (先前稱為安全通訊端層 (SSL)) 是在網頁伺服器與瀏覽器之間建立加密連結的標準安全性技術。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. 此連結可確保在網頁伺服器和瀏覽器之間傳遞的所有資料都保有私密性和加密狀態。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 工作階段識別碼,並管理 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 票證有助於減輕此問題,但並非所有用戶端都支援此功能,且可能難以設定和管理。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,請將 BackendHTTPSetting 中的通訊協定設為 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 App Service/Web Apps 和 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 App Service) 不需進行驗證和信任根憑證設定。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 所簽發且 CN 為 contoso.com,而後端 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 App Service 或其他 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。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) 標頭 (FQDN)SNI (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 位址作為主機名稱,則不會根據 RFC 6066 設定 SNI。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 主機標頭使用,根據 RFC 6066,將不會作為 SNI 標頭使用。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) 標頭 (FQDN)SNI (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 如果後端集區項目不是 FQDN,則不會根據 RFC 6066 設定 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.