Übersicht über TLS-Beendigung und End-to-End-TLS mit Application Gateway

Transport Layer Security (TLS), zuvor bekannt als Secure Sockets Layer (SSL), ist die standardmäßige Sicherheitstechnologie, mit der eine verschlüsselte Verbindung zwischen einem Webserver und einem Browser hergestellt wird. Über diese Verbindung wird sichergestellt, dass alle Daten privat und verschlüsselt zwischen dem Webserver und dem Browser übertragen werden. Application Gateway unterstützt sowohl die TLS-Terminierung am Gateway als auch die End-to-End-TLS-Verschlüsselung.

Wichtig

Ab dem 31. August 2025 müssen alle Clients und Back-End-Server, die mit Azure Application Gateway interagieren, Transport Layer Security (TLS) 1.2 oder höher verwenden, da Unterstützung für TLS 1.0 und 1.1 eingestellt wird.

TLS-Terminierung

Application Gateway unterstützt die TLS-Beendigung am Gateway, wonach der Datenverkehr in der Regel unverschlüsselt zu den Back-End-Servern gelangt. Die TLS-Terminierung am Application Gateway bietet zahlreiche Vorteile:

• Verbesserte Leistung: Der größte Leistungsabfall bei der TLS-Entschlüsselung entsteht beim anfänglichen Handshake. Der Entschlüsselungsserver verbessert die Leistung durch das Zwischenspeichern von TLS-Sitzungs-IDs und das Verwalten von TLS-Sitzungstickets. Wenn dieser Vorgang am Application Gateway erfolgt, können alle Anforderungen vom gleichen Client die zwischengespeicherten Werte verwenden. Wenn dies auf den Backend-Servern geschieht, muss sich der Client jedes Mal neu authentifizieren, wenn seine Anforderungen an einen anderen Server gerichtet sind. Sie können dieses Problem durch die Verwendung von TLS-Tickets beheben, diese werden jedoch nicht von allen Clients unterstützt und können das Konfigurieren und Verwalten erschweren.
• Bessere Auslastung der Back-End-Server: Die SSL/TLS-Verarbeitung bringt eine hohe CPU-Intensität mit sich, die sich mit steigenden Schlüsselgrößen weiter verstärkt. Wenn Sie die Back-End-Server von dieser Aufgabe befreien, können diese für ihren effizientesten Zweck eingesetzt werden: das Bereitstellen von Inhalten.
• Intelligentes Routing: Durch die Entschlüsselung des Datenverkehrs erhält das Anwendungsgateway Zugriff auf Anforderungsinhalte wie Header, URI etc. und kann diese Daten dann zum Weiterleiten von Anforderungen verwenden.
• Zertifikatverwaltung: Zertifikate müssen nicht für alle Back-End-Server, sondern nur für das Anwendungsgateway erworben und installiert werden. Das spart Zeit und Geld.

Zum Konfigurieren der TLS-Terminierung muss dem Listener ein TLS/SSL-Zertifikat hinzugefügt werden. Dadurch kann der Application Gateway eingehenden Datenverkehr entschlüsseln und den Antwortdatenverkehr an den Client verschlüsseln. Das Zertifikat für den Application Gateway muss im PFX-Format (Personal Information Exchange) vorliegen, das sowohl die privaten als auch die öffentlichen Schlüssel enthält. Die unterstützten PFX-Algorithmen sind unter PFXImportCertStore-Funktion aufgeführt.

Wichtig

Das Zertifikat auf dem Listener erfordert das Hochladen der gesamten Zertifikatskette (Stammzertifikat von der Zertifizierungsstelle, die Zwischenzertifikate und untergeordnetes Zertifikat), um die Vertrauenskette herzustellen.

Hinweis

Das Anwendungsgateway bietet keine Funktionen zum Erstellen neuer Zertifikate oder Senden von Zertifikatanforderungen an Zertifizierungsstellen.

Zum Hersteller der TLS-Verbindung müssen Sie sicherstellen, dass das TLS/SSL-Zertifikat die folgenden Bedingungen erfüllt:

• Das aktuelle Datum und die aktuelle Uhrzeit entsprechen den Datumsbereichen „Gültig ab“ und „Gültig bis“ im Zertifikat.
• Der allgemeine Name (Common Name, CN) des Zertifikats entspricht dem Hostheader in der Anforderung. Wenn der Client eine Anforderung beispielsweise an https://www.contoso.com/ richtet, muss der CN www.contoso.com lauten.

Wenn Fehler mit dem gemeinsamen Back-End-Zertifikatnamen (Common Name, CN) auftreten, lesen Sie unsere Anleitung zur Problembehandlung.

Unterstützte Zertifikate für die TLS-Beendigung

Das Anwendungsgateway unterstützt die folgenden Arten von Zertifikaten:

• ZS (Zertifizierungsstellen)-Zertifikat: Ein ZS-Zertifikat ist ein digitales Zertifikat, das von einer Zertifizierungsstelle (Certificate Authority, ZS) ausgestellt wurde.
• EV (Extended Validation)-Zertifikat: Ein EV-Zertifikat ist ein Zertifikat, das den Branchen-Standardzertifikatrichtlinien entspricht. Die Locator-Leiste des Browsers wird dadurch grün, und auch der Firmennamen wird veröffentlicht.
• Platzhalterzertifikat: Dieses Zertifikat unterstützt eine beliebige Anzahl von untergeordneten Domänen basierend auf *.site.com., wobei Ihre Subdomäne das * ersetzen würde. Es unterstützt jedoch nicht site.com. Falls Ihre Benutzer*innen auf Ihre Website zugreifen, ohne die führende Zeichenfolge „www“ einzugeben, wird das Platzhalterzertifikat diese Eingabe nicht berücksichtigen.
• Selbstsignierte Zertifikate: Clientbrowser vertrauen diesen Zertifikaten nicht und warnen den Benutzer, dass das virtuelle Zertifikat des Diensts keiner Vertrauenskette angehört. Selbstsignierte Zertifikate eignen sich gut für Tests oder Umgebungen, in denen Administratoren die Clients kontrollieren und Sicherheitswarnungen des Browsers sicher umgehen können. Produktionsworkloads sollten niemals selbstsignierte Zertifikate verwenden.

Weitere Informationen finden Sie im Artikel zum Konfigurieren der TLS-Terminierung mit Application Gateway.

Größe des Zertifikats

Lesen Sie den Abschnitt Application Gateway-Grenzwerte durch, um die maximal unterstützte Größe von TLS/SSL-Zertifikaten zu erfahren.

End-to-End-TLS-Verschlüsselung

Möglicherweise möchten Sie keine unverschlüsselte Kommunikation mit den Back-End-Servern verwenden. Möglicherweise sollen Sicherheits- oder Complianceanforderungen erfüllt werden, oder in der Anwendung wird nur eine sichere Verbindung akzeptiert. Im Hinblick auf diese Anforderungen unterstützt Azure Application Gateway die End-to-End-TLS-Verschlüsselung.

End-to-End-TLS ermöglicht Ihnen die Verschlüsselung und sichere Übertragung vertraulicher Daten an das Back-End bei Verwendung der Lastenausgleichsfunktionen von Schicht 7 von Application Gateway. Zu diesen Funktionen zählen unter anderem cookiebasierte Sitzungsaffinität, URL-basiertes Routing, Unterstützung von standortbasiertem Routing und die Möglichkeit zum Umschreiben oder Einfügen von Headern vom Typ „X-Forwarded-*“.

Bei der Konfiguration mit dem End-to-End-TLS-Kommunikationsmodus beendet Application Gateway die TLS-Sitzungen am Gateway und entschlüsselt den Benutzerdatenverkehr. Anschließend werden die konfigurierten Regeln angewendet, um eine geeignete Instanz des Back-End-Pools auszuwählen, an die der Datenverkehr geroutet werden soll. Application Gateway initiiert anschließend eine neue TLS-Verbindung mit dem Back-End-Server und verschlüsselt die Daten mit dem öffentlichen Schlüssel des Back-End-Serverzertifikats erneut, bevor die Anforderung an das Back-End übertragen wird. Antworten vom Webserver durchlaufen denselben Prozess zurück an den Endbenutzer. End-to-End-TLS wird aktiviert, indem Sie die Protokolleinstellung in der Back-End-HTTP-Einstellung auf „HTTPS“ festlegen. Diese Einstellung wird anschließend auf einen Back-End-Pool angewandt.

In Anwendungsgateway v1-SKU-Gateways wendet die TLS-Richtlinie die TLS-Version nur auf Frontend-Datenverkehr und die definierten Verschlüsselungsverfahren auf Frontend- und Back-End-Ziele an. In Anwendungsgateway v2-SKU-Gateways gilt TLS-Richtlinie nur für Front-End-Datenverkehr, Back-End-TLS-Verbindungen werden immer über TLS 1.0 zu TLS 1.2-Versionen ausgehandelt.

Application Gateway kommuniziert nur mit den Back-End-Servern, deren Zertifikat in der Zulassungsliste von Application Gateway enthalten ist oder deren Zertifikate von bekannten Zertifizierungsstellen signiert wurden und deren CN mit dem Hostnamen in den HTTP-Einstellungen auf dem Back-End übereinstimmt. Dazu zählen vertrauenswürdige Azure-Dienste wie Azure App Service oder Azure App Service-Web-Apps und Azure API Management.

Wenn die Zertifikate der Mitglieder im Back-End-Pool nicht von bekannten Zertifizierungsstellen signiert wurden, muss jede Instanz im Back-End-Pool mit aktiviertem End-to-End-TLS mit einem Zertifikat konfiguriert werden, um die sichere Kommunikation zu ermöglichen. Durch das Hinzufügen des Zertifikats wird sichergestellt, dass das Anwendungsgateway nur mit bekannten Back-End-Instanzen kommuniziert. Außerdem wird auf diese Weise die End-to-End-Kommunikation gesichert.

Hinweis

Das Zertifikat, das der Back-End-HTTP-Einstellung zum Authentifizieren der Back-End-Server hinzugefügt wurde, kann mit dem Zertifikat übereinstimmen, das dem Listener zur TLS-Terminierung am Anwendungsgateway oder an einer anderen Instanz hinzugefügt wurde, um die Sicherheit zu verbessern.

In diesem Beispiel werden Anforderungen, für die TLS 1.2 verwendet wird, an Back-End-Server in Pool1 geleitet, indem End-to-End-TLS genutzt wird.

End-to-End-TLS und Zulassungslisten für Zertifikate

Application Gateway kommuniziert nur mit den Back-End-Servern, deren Zertifikat in der Zulassungsliste von Application Gateway enthalten ist oder deren Zertifikate von bekannten Zertifizierungsstellen signiert wurden und deren CN mit dem Hostnamen in den HTTP-Einstellungen auf dem Back-End übereinstimmt. In Bezug auf die verwendete Version von Application Gateway gibt es einige Unterschiede beim Prozess zum Einrichten von End-to-End-TLS. Im folgenden Abschnitt werden die Versionen einzeln erläutert.

End-to-End-TLS mit der v1-SKU

Zum Aktivieren von End-to-End-TLS mit den Back-End-Servern und zum Weiterleiten von Anforderungen durch Application Gateway an die Back-End-Server müssen die Integritätstests erfolgreich durchgeführt werden und eine fehlerfreie Antwort zurückgeben.

Bei HTTPS-Integritätstests verwendet die Application Gateway v1-SKU eine genaue Entsprechung des Authentifizierungszertifikats (öffentlicher Schlüssel des Back-End-Serverzertifikats anstelle des Stammzertifikats), das in die HTTP-Einstellungen hochgeladen werden soll.

Es sind dann nur Verbindungen mit bekannten und zulässigen Back-Ends gestattet. Die übrigen Back-End-Server werden in den Integritätstests als fehlerhaft eingestuft. Selbstsignierte Zertifikate dienen nur zu Testzwecken und werden für Produktionsworkloads nicht empfohlen. Solche Zertifikate müssen, wie unter den obigen Schritten beschrieben, in der Zulassungsliste des Anwendungsgateways enthalten sein, damit sie verwendet werden können.

Hinweis

Die Einrichtung des Authentifizierungszertifikats und des vertrauenswürdigen Stammzertifikats ist für vertrauenswürdige Azure-Dienste wie Azure App Service nicht erforderlich. Diese Zertifikate werden standardmäßig als vertrauenswürdig eingestuft.

End-to-End-TLS mit der v2-SKU

Authentifizierungszertifikate wurden als veraltet markiert und durch Trusted Root-Zertifikate in der v2-SKU von Application Gateway ersetzt. Sie funktionieren auf ähnliche Weise wie Authentifizierungszertifikate mit einigen wichtigen Unterschieden:

• Zertifikate, die von bekannten Zertifizierungsstellen, deren CN dem Hostnamen in den HTTP-Einstellungen des Back-Ends entspricht, zertifiziert wurden, erfordern keinen zusätzlichen Schritt, damit End-to-End-TLS funktioniert.

  Wenn beispielsweise die Back-End-Zertifikate von einer bekannten Zertifizierungsstelle ausgestellt wurden, der CN „contoso.com“ lautet und in der HTTP-Einstellung des Back-Ends das Feld „Host“ ebenfalls auf „contoso.com“ festgelegt wurde, sind keine weiteren Schritte erforderlich. Sie können das Protokoll in der HTTP-Einstellung des Back-Ends auf HTTPS festlegen. In diesem Fall ist TLS sowohl für den Integritätstest als auch für den Datenpfad aktiviert. Wenn Sie Azure App Service oder andere Azure-Webdienste als Back-End verwenden, gelten diese ebenfalls als implizit vertrauenswürdig, und für End-to-End-TLS sind keine weiteren Schritte erforderlich.

Hinweis

Damit ein TLS/SSL-Zertifikat als vertrauenswürdig eingestuft wird, muss dieses Zertifikat des Back-End-Servers von einer bekannten Zertifizierungsstelle ausgestellt worden sein. Wenn das Zertifikat nicht von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wurde, überprüft das Anwendungsgateway, ob das Zertifikat der ausstellenden Zertifizierungsstelle von einer vertrauenswürdigen Zertifizierungsstelle stammt. Dieser Vorgang wird so lange fortgesetzt, bis entweder eine vertrauenswürdige Zertifizierungsstelle gefunden wurde (woraufhin eine vertrauenswürdige, sichere Verbindung hergestellt wird) oder keine vertrauenswürdige Zertifizierungsstelle gefunden werden kann (woraufhin das Back-End vom Anwendungsgateway als fehlerhaft markiert wird). Das Back-End-Serverzertifikat sollte daher sowohl die Stammzertifizierungsstelle als auch die Zwischenzertifizierungsstellen enthalten.

• Wenn das Zertifikat des Back-End-Servers selbstsigniert ist oder von einer unbekannten Zertifizierungsstelle oder einem unbekannten Vermittler signiert wurde, müssen Sie zum Aktivieren von End-to-End-TLS in Application Gateway v2 ein vertrauenswürdiges Stammzertifikat hochladen. Application Gateway kommuniziert nur mit Back-Ends, bei denen das Stammzertifikat des Serverzertifikats mit einem der vertrauenswürdigen Stammzertifikate in der Liste der HTTP-Einstellung für das Back-End übereinstimmt, das dem Pool zugeordnet ist.

• Zusätzlich zur Übereinstimmung des Stammzertifikats überprüft Application Gateway v2 auch, ob die Einstellung „Host“ in der HTTP-Einstellung des Back-Ends mit dem allgemeinen Namen (Common Name, CN) übereinstimmt, der vom TLS/SSL-Zertifikat des Back-End-Servers angegeben wird. Beim Herstellen einer TLS-Verbindung mit dem Back-End legt Application Gateway v2 die SNI-Erweiterung (Server Name Indication, Servernamensanzeige) auf den Host fest, der in der HTTP-Einstellung des Back-Ends angegeben wurde.

• Wenn Hostname aus Back-End-Ziel auswählen anstelle des Felds Host in der Back-End-HTTP-Einstellung ausgewählt wird, wird der SNI-Header immer auf den FQDN des Back-End-Pools gesetzt und der CN auf dem TLS/SSL-Zertifikat des Back-End-Servers muss übereinstimmen seinen FQDN. Mitglieder des Back-End-Pools mit IP-Adressen werden in diesem Szenario nicht unterstützt.

• Das Stammzertifikat ist ein Base64-codiertes Stammzertifikat aus den Zertifikaten des Back-End-Servers.

SNI-Unterschiede in der v1- und v2-SKU

Wie zuvor erwähnt, beendet Application Gateway den TLS-Datenverkehr vom Client beim Application Gateway-Listener (d. h. die Front-End-Verbindung), entschlüsselt den Datenverkehr, wendet die erforderlichen Regeln an, um den Back-End-Server zu ermitteln, an den die Anforderung weitergeleitet werden muss, und stellt eine neue TLS-Sitzung mit dem Back-End-Server her (die Back-End-Verbindung).

In den folgenden Tabellen werden die SNI-Unterschiede zwischen der v1-SKU und der v2-SKU hinsichtlich der Front-End- und der Back-End-Verbindung beschrieben.

Front-End-TLS-Verbindung (Client zu Application Gateway)

Szenario	v1	V2
Der Client gibt den SNI-Header an, und alle Listener für mehrere Standorte sind mit dem Flag „Require SNI“ (SNI anfordern) aktiviert.	Gibt das entsprechende Zertifikat zurück. Wenn die Site nicht vorhanden ist (entsprechend „server_name“), wird die Verbindung zurückgesetzt.	Gibt das entsprechende Zertifikat zurück, falls verfügbar, andernfalls wird das Zertifikat des ersten HTTPS-Listeners entsprechend der Reihenfolge zurückgegeben, die durch die den HTTPS-Listenern zugeordneten Anforderungsroutingregeln vorgegeben ist.
Der Client gibt keinen SNI-Header an, und alle Header für mehrere Standorte sind mit „Require SNI“ (SNI anfordern) aktiviert:	Setzt die Verbindung zurück	Gibt das Zertifikat des ersten HTTPS-Listeners entsprechend der Reihenfolge zurück, die durch die den HTTPS-Listenern zugeordneten Anforderungsroutingregeln vorgegeben ist.
Der Client gibt keinen SNI-Header an, und ein mit einem Zertifikat konfigurierter Basislistener ist vorhanden:	Gibt das im Basislistener konfigurierte Zertifikat (Standard- oder Fallbackzertifikat) an den Client zurück	Gibt das im Basislistener konfigurierte Zertifikat zurück

Hinweis

Wenn der Client keinen SNI-Header angibt, wird empfohlen, dem Benutzer einen einfachen Listener und eine Regel hinzuzufügen, um ein Standard-SSL/TLS-Zertifikat zu präsentieren.

Tipp

Das SNI-Flag kann mit PowerShell oder mithilfe einer ARM-Vorlage konfiguriert werden. Weitere Informationen finden Sie unter RequireServerNameIndication und Schnellstart: Direkter Webdatenverkehr mit Azure Application Gateway – ARM-Vorlage.

Back-End-TLS-Verbindung (Application Gateway zum Back-End-Server)

Beim Testdatenverkehr

Szenario	v1	V2
Wenn ein FQDN oder SNI konfiguriert ist	Wird als FQDN über den Back-End-Pool festgelegt. Gemäß RFC 6066 sind IPv4- und IPv6-Literaladressen im SNI-Hostnamen nicht zulässig.	Der SNI-Wert wird basierend auf dem TLS-Überprüfungstyp in den Back-End-Einstellungen festgelegt. 1. Vollständige Validierung – Die Sonden verwenden den SNI in der folgenden Reihenfolge: a) Hostname des benutzerdefinierten Integritätstests b) Hostname der Back-End-Einstellung (gemäß Außerkraftsetzungswert oder Auswahl vom Back-End-Server) 2. Konfigurierbar Verwenden Sie spezifische SNI: Die Proben verwenden diesen festen Hostnamen für die Validierung. SNI überspringen: Keine Überprüfung des Antragstellernamens.
Wenn ein FQDN oder SNI NICHT konfiguriert ist (nur IP-Adresse ist verfügbar)	SNI (server_name) wird nicht festgelegt. Hinweis: In diesem Fall sollte der Back-End-Server ein Standard- oder Fallbackzertifikat zurückgeben können. Dieses sollte in den HTTP-Einstellungen unter dem Authentifizierungszertifikat in der Zulassungsliste enthalten sein. Wenn auf dem Back-End-Server kein Standard- oder Fallbackzertifikat konfiguriert ist und die SNI erwartet wird, setzt der Server die Verbindung möglicherweise zurück, was zu Testfehlern führt.	Wenn die Benutzerdefinierten Probe- oder Back-End-Einstellungen eine IP-Adresse im Hostnamenfeld verwenden, wird der SNI nicht gemäß RFC 6066 festgelegt. Dies schließt Fälle ein, in denen die Standardprobe 127.0.0.1 verwendet wird.

Beim Livedatenverkehr

Szenario	v1	V2
Wenn ein FQDN oder SNI verfügbar ist	Der SNI wird mit dem FQDN des Back-End-Servers festgelegt.	Der SNI-Wert wird basierend auf dem TLS-Überprüfungstyp in den Back-End-Einstellungen festgelegt. 1. Vollständige Validierung – SNI wird gemäß der folgenden Reihenfolge der Rangfolge festgelegt: b) Hostname der Back-End-Einstellung (gemäß Außerkraftsetzungswert oder Auswahl vom Back-End-Server) b) Hostheader der eingehenden Clientanforderung 2. Konfigurierbar Verwenden Sie bestimmte SNI: Verwendet diesen festen Hostnamen für die Überprüfung. SNI überspringen: Keine Überprüfung des Antragstellernamens.
Wenn ein FQDN oder SNI NICHT verfügbar ist (nur IP-Adresse ist verfügbar)	Die SNI wird gemäß RFC 6066 nicht festgelegt, wenn der Eintrag des Back-End-Pools kein FQDN ist.	SNI wird nicht gemäß RFC 6066 festgelegt.

Nächste Schritte

Nachdem Sie sich über End-to-End-TLS informiert haben, fahren Sie mit dem Konfigurieren von End-to-End-TLS mit Application Gateway und PowerShell fort, um ein Anwendungsgateway mit End-to-End-TLS zu erstellen.