應用程式閘道的 TLS 終止和端對端 TLS 概觀

傳輸層安全性 (TLS) (先前稱為安全通訊端層 (SSL)) 是在網頁伺服器與瀏覽器之間建立加密連結的標準安全性技術。 此連結可確保在網頁伺服器和瀏覽器之間傳遞的所有資料都保有私密性和加密狀態。 應用程式閘道支援閘道上的 TLS 終止以及端對端 TLS 加密。

TLS 終止

應用程式閘道支援在閘道上終止 TLS，之後流量通常會以未加密狀態流至後端伺服器。 在應用程式閘道上進行 TLS 終止有幾個優點：

• 提升效能 – 進行 TLS 解密時最大的效能影響，在於初始交握。 為了改善效能，進行解密的伺服器會快取 TLS 工作階段識別碼，並管理 TLS 工作階段票證。 如果在應用程式閘道上執行此動作，來自相同用戶端的所有要求都可以使用快取值。 如果在後端伺服器上執行此動作，則每次用戶端的要求傳至不同的伺服器時，用戶端都必須重新驗證。 使用 TLS 票證有助於減輕此問題，但並非所有用戶端都支援此功能，且可能難以設定和管理。
• 改善後端伺服器使用率 – SSL/TLS 處理會耗用大量 CPU，且隨著金鑰大小的增加，耗用量會更大。 從後端伺服器中移除此工作，可使其專注於最有效率的工作，即傳遞內容。
• 智慧型路由 – 藉由解密流量，應用程式閘道得以存取要求內容 (例如標頭、URI 等)，並可使用這項資料來路由要求。
• 憑證管理 – 憑證在購買後只需安裝在應用程式閘道上，而不是所有後端伺服器。 這可以節省時間和金錢。

若要設定 TLS 終止，必須將 TLS/SSL 憑證新增至接聽程式。 這可讓應用程式閘道解密傳入流量，並將對用戶端的回應流量加密。 提供給應用程式閘道的憑證必須是個人資訊交換 (PFX) 格式，其包含私密金鑰和公開金鑰。 支援的 PFX 演算法會列在 PFXImportCertStore 函式中。

若要讓 TLS 連線正常運作，您必須確定 TLS/SSL 憑證符合下列條件：

• 目前的日期和時間在憑證的「有效期限自」和「有效期限至」日期範圍內。
• 憑證的「一般名稱」(CN) 符合要求中的主機標頭。 例如，如果用戶端提出 https://www.contoso.com/ 要求，則 CN 必須是 www.contoso.com。

如果後端憑證通用名稱 (CN) 有錯誤，請參閱疑難排解指南。

支援 TLS 終止的憑證

應用程式閘道支援下列類型的憑證：

• CA (憑證授權單位) 憑證：CA 憑證是憑證授權單位 (CA) 所發行的數位憑證
• EV (擴充驗證) 憑證：EV 憑證是符合業界標準憑證指導方針的憑證。 此憑證會使瀏覽器定位器列變成綠色，並同時發佈公司名稱。
• 萬用字元憑證：此憑證支援以 *.site.com 為基礎的子網域 (數量不限)，而您的子網域會取代其中的 *。 但並不支援 site.com，因此，如果使用者在存取您的網站時未輸入前置的 "www"，萬用字元憑證就不會將其涵蓋在內。
• 自我簽署憑證：用戶端瀏覽器不信任這些憑證，且會警告使用者，指出虛擬服務的憑證不是信任鏈結的一部分。 自我簽署憑證適用於由系統管理員控制用戶端，且可安全略過瀏覽器安全性警示的測試或環境。 生產工作負載不得使用自我簽署憑證。

如需詳細資訊，請參閱設定應用程式閘道的 TLS 終止。

憑證的大小

請查看應用程式閘道限制一節，以了解支援的 TLS/SSL 憑證大小上限。

端對端 TLS 加密

您可能不想要對後端伺服器進行未加密的通訊。 您可能有安全性需求、合規性需求，或應用程式可能只接受安全連線。 Azure 應用程式閘道具有端對端 TLS 加密，可支援這些需求。

當您使用應用程式閘道的第 7 層負載平衡功能時，端對端 TLS 可讓您加密敏感性資料，並安全地將其傳輸至後端。 這些功能包括 Cookie 型工作階段親和性、URL 型路由、支援以網站為基礎的路由，以及重寫或插入 X-Forwarded-* 標頭的能力。

當設定為端對端 TLS 通訊模式時，應用程式閘道會在閘道上終止 TLS 工作階段，並解密使用者流量。 然後，它會套用所設定的規則來選取要將流量路由傳送到的適當後端集區執行個體。 應用程式閘道接著再起始連往後端伺服器的新 TLS 連線，並先使用後端伺服器的公開金鑰憑證重新加密資料，再將要求傳輸至後端。 任何來自 Web 伺服器的回應都會經歷相同的程序而回到使用者端。 若要啟用端對端 TLS，請將 BackendHTTPSetting 中的通訊協定設為 HTTPS，接著再套用到後端集區。

在應用程式閘道 v1 SKU 閘道中，TLS 原則只會將 TLS 版本套用至前端流量，並將定義的加密同時套用至前端和後端目標。 在應用程式閘道 v2 SKU 閘道中，TLS 原則僅適用於前端流量，後端 TLS 連線一律會透過 TLS 1.0 與 TLS 1.2 版本交涉。

應用程式閘道只會與符合下列條件的後端伺服器進行通訊：已將伺服器用於應用程式閘道的憑證列入允許清單中，或已由知名的 CA 授權單位簽署其憑證，且憑證的 CN 符合 HTTP 後端設定中的主機名稱。 其中包括受信任的 Azure 服務，例如 Azure App Service/Web Apps 和 Azure API 管理。

如果後端集區中的成員未由知名的 CA 授權單位簽署其憑證，則後端集區中每個已啟用端對端 TLS 的執行個體都必須進行憑證設定，以支援安全通訊。 新增憑證可確保應用程式閘道只會與已知的後端執行個體通訊。 這會進而保護端對端通訊。

在此範例中，會使用端對端 TLS，將使用 TLS1.2 的要求路由傳送至 Pool1 中的後端伺服器。

端對端 TLS 和憑證允許清單

應用程式閘道只會與符合下列條件的後端伺服器進行通訊：已將伺服器用於應用程式閘道的憑證列入允許清單中，或已由知名的 CA 授權單位簽署其憑證，且憑證的 CN 符合 HTTP 後端設定中的主機名稱。 端對端 TLS 設定程序在使用的應用程式閘道版本方面有一些差異。 下一節會個別說明這些版本。

v1 SKU 的端對端 TLS

若要在後端伺服器上啟用端對端 TLS，並讓應用程式閘道將要求路由至該處，健康情況探查必須成功，並傳回狀況良好的回應。

針對 HTTPS 健康情況探查，應用程式閘道 v1 SKU 會使用要上傳至 HTTP 設定且完全相符的驗證憑證 (後端伺服器憑證的公開金鑰，而不是根憑證)。

於是，只允許連接至已知和允許清單中的後端。 健康情況探查會將其餘後端視為狀況不良。 自我簽署憑證僅供測試之用，並不建議用於生產工作負載。 這類憑證必須如先前步驟所述，加入應用程式閘道的允許清單之中，才能使用。

v2 SKU 的端對端 TLS

在「應用程式閘道 v2 SKU」中，「驗證憑證」已被淘汰且被「受信任的根憑證」取代。 它們的功能與「驗證憑證」類似，但有幾個主要差異：

• 憑證如果是由 CN 與 HTTP 後端設定中主機名稱相符的已知 CA 授權單位所簽署，則無須執行任何其他步驟，端對端 TLS 就能運作。

  例如，如果後端憑證是由已知 CA 所簽發且 CN 為 contoso.com，而後端 HTTP 設定的主機欄位也設定為 contoso.com，便無須執行任何其他步驟。 您可以將後端 HTTP 設定通訊協定設定為 HTTPS，健康狀態探查和資料路徑就會都啟用 TLS。 如果您使用 Azure App Service 或其他 Azure Web 服務作為後端，則這些項目也會隱含地受到信任，而無須執行任何進一步的步驟，即可進行端對端 TLS。

• 如果後端伺服器憑證是自我簽署的，或由未知的 CA/媒介所簽署的，則若要在應用程式閘道 v2 中啟用端對端 TLS，就必須上傳受信任的根憑證。 「應用程式閘道」只會與符合下列條件的後端進行通訊：其伺服器憑證的根憑證符合與集區相關之後端 HTTP 設定中受信任根憑證清單內的其中一個憑證。

• 除了根憑證相符之外，應用程式閘道 v2 也會驗證後端 HTTP 設定中所指定的「主機」設定是否符合後端伺服器 TLS/SSL 憑證所出示的通用名稱 (CN)。 嘗試與後端建立 TLS 連線時，應用程式閘道 v2 會將「伺服器名稱指示」(SNI) 延伸模組設定為後端 HTTP 設定中所指定的「主機」。

• 如果選擇從後端目標挑選主機名稱，而不是從後端 HTTP 設定中的 [主機] 欄位挑選，則 SNI 標頭會一律設定為後端集區 FQDN，而後端伺服器 TLS/SSL 憑證上的 CN 必須符合其 FQDN。 此案例不支援具有 IP 的後端集區成員。

• 根憑證是一個來自後端伺服器憑證的 Base64 編碼根憑證。

v1 與 v2 SKU 中的 SNI 差異

如前所述，應用程式閘道會在應用程式閘道接聽程式上終止用戶端的 TLS 流量 (我們將其稱為前端連線)、解密流量、套用必要的規則以決定要求要轉送到的後端伺服器，並與後端伺服器建立新的 TLS 工作階段 (我們將其稱為後端連線)。

下表概述 v1 與 v2 SKU 在前端和後端連線方面的 SNI 差異。

前端 TLS 連線 (用戶端對應用程式閘道)

後端 TLS 連線 (應用程式閘道對後端伺服器)

探查流量

即時流量

下一步

了解端對端 TLS 之後，請移至使用 PowerShell 以應用程式閘道設定端對端 TLS，以使用端對端 TLS 來建立應用程式閘道。