Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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 Client, beispielsweise einem Webbrowser, hergestellt wird. Diese Verbindung stellt sicher, dass alle Daten, die zwischen dem Server und dem Client übertragen werden, privat und verschlüsselt bleiben.
Um Ihre Sicherheits- oder Complianceanforderungen zu erfüllen, unterstützt Azure Front Door die End-to-End-TLS-Verschlüsselung. Die Front Door-TLS/SSL-Auslagerung beendet die TLS-Verbindung, entschlüsselt den Datenverkehr bei Azure Front Door, und verschlüsselt den Datenverkehr erneut, bevor er an den Ursprung weitergeleitet wird. Wenn Verbindungen mit dem Ursprung die öffentliche IP-Adresse des Ursprungs verwenden, ist es eine gute Sicherheitspraxis, HTTPS als Weiterleitungsprotokoll in Ihrer Azure Front Door zu konfigurieren. Wenn Sie HTTPS als Weiterleitungsprotokoll verwenden, können Sie die End-to-End-TLS-Verschlüsselung für die gesamte Verarbeitung der Anforderung vom Client bis zum Ursprung erzwingen. Die TLS/SSL-Auslagerung wird auch unterstützt, wenn Sie einen privaten Ursprung mit Azure Front Door Premium mithilfe des Private Link-Features bereitstellen.
In diesem Artikel wird erläutert, wie Azure Front Door mit TLS-Verbindungen funktioniert. Weitere Informationen zur Verwendung von TLS-Zertifikaten mit Ihren eigenen benutzerdefinierten Domänen finden Sie unter HTTPS für benutzerdefinierte Domänen. Informationen zum Konfigurieren eines TLS-Zertifikats in Ihrer eigenen benutzerdefinierten Domäne finden Sie unter Konfigurieren einer benutzerdefinierten Domäne in Azure Front Door mithilfe des Azure-Portals.
End-to-End-TLS-Verschlüsselung
Mit End-to-End-TLS können Sie vertrauliche Daten während der Übertragung an den Ursprung sichern und gleichzeitig von Azure Front Door-Features wie z. B. einem globalem Lastenausgleich und Zwischenspeichern profitieren. Weitere Features sind u. a. das URL-basierte Routing, die TCP-Aufteilung, das Zwischenspeichern an dem Edge-Standort, der den Clients am nächsten ist und das benutzerdefinierte Anpassen von HTTP-Anforderungen am Edge.
Azure Front Door lagert die TLS-Sitzungen am Edge aus und entschlüsselt Clientanforderungen. Anschließend werden die konfigurierten Routingregeln angewendet, um die Anforderungen an den entsprechenden Ursprung in der Ursprungsgruppe weiterzuleiten. Azure Front Door stellt dann eine neue TLS-Verbindung mit dem Ursprung her und verschlüsselt alle Daten mithilfe des Zertifikats des Ursprungs erneut, bevor die Anforderung an den Ursprung übertragen wird. Jede Antwort vom Ursprung wird durch denselben Prozess verschlüsselt und an den Endbenutzer zurückgesendet. Sie können Azure Front Door so konfigurieren, dass HTTPS als Weiterleitungsprotokoll verwendet wird, um End-to-End-TLS zu aktivieren.
Unterstützte TLS-Versionen
Azure Front Door unterstützt zwei Versionen des TLS-Protokolls: TLS-Versionen 1.2 und 1.3. Alle azure Front Door-Profile, die nach September 2019 erstellt wurden, verwenden TLS 1.2 als Standard-Minimum, wobei TLS 1.3 aktiviert ist. Derzeit unterstützt Azure Front Door keine Client-/gegenseitige Authentifizierung (mTLS).
Wichtig
Ab dem 1. März 2025 sind TLS 1.0 und 1.1 für neue Azure Front Door-Profile nicht zulässig.
Für Azure Front Door Standard und Premium können Sie vordefinierte TLS-Richtlinie konfigurieren oder die TLS-Verschlüsselungssuite basierend auf den Sicherheitsanforderungen Ihrer Organisation auswählen. Weitere Informationen finden Sie unter Azure Front Door TLS-Richtlinie und Konfigurieren der TLS-Richtlinie für eine benutzerdefinierte Front Door-Domäne.
Für azure Front Door classic und Microsoft CDN classic können Sie die minimale TLS-Version in Azure Front Door in den benutzerdefinierten Domänen-HTTPS-Einstellungen mithilfe des Azure-Portals oder der Azure REST-API konfigurieren. Für eine minimale TLS-Version 1.2 versucht die Aushandlung, TLS 1.3 und dann TLS 1.2 einzurichten. Wenn Azure Front Door TLS-Datenverkehr an den Ursprung initiiert, versucht es, die beste TLS-Version auszuhandeln, die vom Ursprung zuverlässig und konsistent akzeptiert werden kann. Unterstützte TLS-Versionen für Ursprungsverbindungen sind TLS 1.2 und TLS 1.3. Wenn Sie die Verschlüsselungssuite pro Bedarf anpassen möchten, migrieren Sie den Klassischen Front Door und den Microsoft CDN-Klassiker zu Azure Front Door Standard und Premium.
Hinweis
- Um eine der Microsoft SDL-kompatiblen EC-Kurven zu unterstützen (einschließlich Secp384r1, Secp256r1 und Secp521) und um erfolgreich Anforderungen mit Azure Front Door über TLS 1.3 durchzuführen, sind Clients mit aktiviertem TLS 1.3 erforderlich.
- Es wird empfohlen, dass Clients eine dieser Kurven als bevorzugte Kurve bei Anforderungen verwenden, um eine erhöhte TLS-Handshakelatenz beim Aushandeln der EC-Kurve zu vermeiden, die sich aus mehreren Roundtrips ergeben kann.
Unterstützte Zertifikate
Wenn Sie Ihr TLS/SSL-Zertifikat erstellen, müssen Sie eine vollständige Zertifikatkette mit einer zulässigen Zertifizierungsstelle erstellen, die in der Microsoft-Liste der vertrauenswürdigen Zertifizierungsstellen enthalten ist. Bei Verwendung einer unzulässigen Zertifizierungsstelle wird Ihre Anforderung abgelehnt.
Zertifikate von internen Zertifizierungsstellen oder selbstsignierte Zertifikate sind nicht zulässig.
OCSP-Anheftung (Online Certificate Status Protocol)
OCSP-Stapling wird in Azure Front Door standardmäßig unterstützt und erfordert keine Konfiguration.
Ursprung-TLS-Verbindung (Azure Front Door zum Ursprung)
Bei HTTPS-Verbindungen erwartet Azure Front Door, dass Ihr Ursprung ein Zertifikat von einer gültigen Zertifizierungsstelle (ZS) mit einem Antragstellernamen vorlegt, der mit dem Hostnamen des Ursprungs übereinstimmt. Wenn beispielsweise der Ursprungshostname auf myapp-centralus.contoso.net festgelegt ist und das Zertifikat, das Ihr Ursprung während des TLS-Handshakes vorlegt, weder myapp-centralus.contoso.net noch *.contoso.net im Betreffnamen aufweist, dann verweigert Azure Front Door die Verbindung, und der Client wird einen Fehler erhalten.
Hinweis
Das Zertifikat muss über eine vollständige Zertifikatkette mit Blatt- und Zwischenzertifikaten verfügen. Die Stammzertifizierungsstelle muss in der Microsoft-Liste der vertrauenswürdigen Zertifizierungsstellen enthalten sein. Wenn ein Zertifikat ohne vollständige Kette präsentiert wird, funktionieren die Anforderungen mit diesem Zertifikat nicht wie erwartet.
In bestimmten Anwendungsfällen, z. B. Tests, können Sie die Zertifikatnamenüberprüfungen für Ihre Azure Front Door deaktivieren, um fehlerhafte HTTPS-Verbindungen zu beheben. Der Ursprung muss weiterhin ein Zertifikat mit einer gültigen, vertrauenswürdigen Kette präsentieren, muss aber nicht mit dem Ursprungshostnamen übereinstimmen.
In Azure Front Door Standard und Premium können Sie einen Ursprung konfigurieren, um die Überprüfung des Zertifikatantragstellernamens zu deaktivieren.
In Azure Front Door (klassisch) können Sie die Überprüfung des Zertifikatantragstellernamens deaktivieren, indem Sie die Azure Front Door-Einstellungen im Azure-Portal ändern. Sie können die Überprüfung auch mithilfe der Einstellungen des Back-End-Pools in den Azure Front Door-APIs konfigurieren.
Hinweis
Aus Sicherheitsgründen empfiehlt Microsoft, die Überprüfung des Zertifikatantragstellernamens nicht zu deaktivieren.
Front-End-TLS-Verbindung (Client zu Azure Front Door)
Um das HTTPS-Protokoll für die sichere Bereitstellung von Inhalten in einer benutzerdefinierten Azure Front Door-Domäne zu aktivieren, können Sie ein von Azure Front Door verwaltetes oder Ihr eigenes Zertifikat verwenden.
Weitere Informationen finden Sie unter HTTPS für benutzerdefinierte Domänen.
Ein von Azure Front Door verwaltetes Zertifikat stellt über DigiCert ein TLS/SSL-Standardzertifikat zur Verfügung und wird im Key Vault von Azure Front Door gespeichert.
Wenn Sie ein eigenes Zertifikat verwenden möchten, können Sie ein Zertifikat einer unterstützten Zertifizierungsstelle integrieren. Hierbei kann es sich um ein Standard-TLS-, ein erweitertes Validierungs- oder sogar um ein Platzhalterzertifikat handeln. Selbstsignierte Zertifikate werden nicht unterstützt. Weitere Informationen zu Aktivieren von HTTPS für eine benutzerdefinierte Domäne.
Automatische Zertifikatrotation
Von Azure Front Door verwaltete Zertifikate werden innerhalb von 90 Tagen vor dem Ende der Ablaufzeit automatisch von Azure Front Door zur neuesten Version rotiert. Von Azure Front Door verwaltete Standard-/Premium-Zertifikate werden innerhalb von 45 Tagen vor dem Ende der Ablaufzeit automatisch von Azure Front Door zur neuesten Version rotiert. Wenn Sie ein von Azure Front Door verwaltetes Zertifikat verwenden und feststellen, dass das Ablaufdatum des Zertifikats weniger als 60 Tage oder, was die Standard-/Premium-SKU angeht, weniger als 30 Tage entfernt ist, sollten Sie ein Supportticket erstellen.
Für Ihr eigenes benutzerdefiniertes TLS/SSL-Zertifikat:
Legen Sie die geheime Version auf "Neueste" fest, damit das Zertifikat automatisch auf die neueste Version gedreht wird, wenn eine neuere Version des Zertifikats im Schlüsseltresor verfügbar ist. Bei benutzerdefinierten Zertifikaten wird das Zertifikat innerhalb von 3 bis 4 Tagen unabhängig von der Ablauffrist automatisch zu einer neueren Version des Zertifikats rotiert.
Bei der Auswahl einer bestimmten Version wird die automatische Rotation nicht unterstützt. Sie müssen die neue Version manuell erneut auswählen, um das Zertifikat zu drehen. Es dauert bis zu 24 Stunden, bis die neue Version des Zertifikats/Geheimnisses bereitgestellt wird.
Hinweis
Verwaltete Azure Front Door-Zertifikate (Standard und Premium) werden automatisch rotiert, wenn der CNAME-Domäneneintrag direkt auf einen Front Door-Endpunkt oder indirekt auf einen Traffic Manager-Endpunkt verweist. Andernfalls müssen Sie das Domäneneigentum erneut überprüfen, um die Zertifikate zu rotieren.
Der Dienstprinzipal für Azure Front Door muss Zugriff auf den Azure Key Vault haben. Der aktualisierte Zertifikatrolloutvorgang von Azure Front Door verursacht keine Downtime in der Produktion, sofern sich der Antragstellername oder der alternative Antragstellername (Subject Alternate Name, SAN) für das Zertifikat nicht geändert haben.
Unterstützte Cipher-Suiten
Für TLS 1.2/1.3 werden die folgenden Verschlüsselungssammlungen unterstützt:
- TLS_AES_256_GCM_SHA384 (nur TLS 1.3)
- TLS_AES_128_GCM_SHA256 (nur TLS 1.3)
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Hinweis
Alte TLS-Versionen und schwache Verschlüsselungen werden nicht mehr unterstützt.
Verwenden Sie die TLS-Richtlinie , um bestimmte Verschlüsselungssammlungen zu konfigurieren. Azure Front Door Standard und Premium bieten zwei Mechanismen für die Steuerung der TLS-Richtlinie: Sie können entweder eine vordefinierte Richtlinie oder eine benutzerdefinierte Richtlinie je nach Ihren eigenen Anforderungen verwenden. Weitere Informationen finden Sie unter Konfigurieren der TLS-Richtlinie für eine benutzerdefinierte Front Door-Domäne.
Hinweis
Für Windows 10 und höhere Versionen wird empfohlen, eine oder beide Suites mit ECDHE_GCM-Verschlüsselungsverfahren zu aktivieren, um die Sicherheit zu erhöhen. Windows 8.1, 8 und 7 sind nicht mit diesen Suites mit ECDHE_GCM-Verschlüsselungsverfahren kompatibel. Die Suites mit ECDHE_GCM- und DHE-Verschlüsselungsverfahren wurden aus Gründen der Kompatibilität mit diesen Betriebssystemen bereitgestellt.