Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Verwenden Sie HTTPS mit CloudFront
Sie können festlegen CloudFront , dass Zuschauer HTTPS verwenden müssen, sodass Verbindungen bei der CloudFront Kommunikation mit Zuschauern verschlüsselt werden. Sie können auch so konfigurieren CloudFront , dass HTTPS für Ihren Ursprung verwendet wird, sodass Verbindungen bei der CloudFront Kommunikation mit Ihrem Ursprung verschlüsselt werden.
Wenn du so konfigurierst CloudFront , dass HTTPS sowohl für die Kommunikation mit Zuschauern als auch für die Kommunikation mit deinem Absender erforderlich ist, passiert Folgendes, wenn du CloudFront eine Anfrage erhältst:
1. Ein Zuschauer sendet eine HTTPS-Anfrage an CloudFront. Hier gibt es einige SSL/TLS Verhandlungen zwischen dem Zuschauer und CloudFront. Am Ende sendet der Viewer die Anfrage in einem verschlüsselten Format.
1. Wenn der CloudFront Edge-Standort eine zwischengespeicherte Antwort enthält, CloudFront verschlüsselt die Antwort und gibt sie an den Viewer zurück, und der Viewer entschlüsselt sie.
1. Wenn der CloudFront Edge-Standort keine zwischengespeicherte Antwort enthält, CloudFront führt er eine SSL/TLS-Aushandlung mit Ihrem Ursprung durch und leitet die Anfrage nach Abschluss der Verhandlung in einem verschlüsselten Format an Ihren Ursprung weiter.
1. Ihr Absender entschlüsselt die Anfrage, verarbeitet sie (generiert eine Antwort), verschlüsselt die Antwort und gibt die Antwort an zurück. CloudFront
1. CloudFront entschlüsselt die Antwort, verschlüsselt sie erneut und leitet sie an den Betrachter weiter. CloudFrontspeichert die Antwort auch am Edge-Standort im Cache, sodass sie bei der nächsten Anforderung verfügbar ist.
1. Der Viewer entschlüsselt die Antwort.
Der Prozess funktioniert im Grunde auf die gleiche Weise, unabhängig davon, MediaStore ob es sich bei Ihrem Ursprung um einen Amazon S3 S3-Bucket oder um einen benutzerdefinierten Ursprung wie einen HTTP/S-Server handelt.
**Anmerkung**
Um Angriffe vom Typ SSL-Neuaushandlung zu verhindern, werden Neuverhandlungen für Zuschauer- und CloudFront Ursprungsanfragen nicht unterstützt.
Alternativ können Sie die gegenseitige Authentifizierung für Ihre Distribution aktivieren. CloudFront Weitere Informationen finden Sie unter [Gegenseitige TLS-Authentifizierung mit CloudFront (Viewer mTLS)Mutual TLS (Herkunft) mit CloudFront](mtls-authentication.md).
In den folgenden Themen finden Sie Informationen dazu CloudFront, wie Sie HTTPS zwischen Zuschauern CloudFront und zwischen und Ihrer Herkunft verlangen können.
**Topics**
+ [Erfordert HTTPS zwischen Zuschauern und CloudFront](using-https-viewers-to-cloudfront.md)
+ [Erzwingen von HTTPS für einen benutzerdefinierten Ursprung](using-https-cloudfront-to-custom-origin.md)
+ [Erzwingen von HTTPS für einen Amazon-S3-Ursprung](using-https-cloudfront-to-s3-origin.md)
+ [Unterstützte Protokolle und Chiffren zwischen Zuschauern und CloudFront](secure-connections-supported-viewer-protocols-ciphers.md)
+ [Unterstützte Protokolle und Chiffren zwischen und dem Ursprung CloudFront](secure-connections-supported-ciphers-cloudfront-to-origin.md)
# Erfordert HTTPS für die Kommunikation zwischen Zuschauern und CloudFront
Sie können ein oder mehrere Cache-Verhalten in Ihrer CloudFront Distribution so konfigurieren, dass HTTPS für die Kommunikation zwischen Zuschauern und erforderlich ist CloudFront. Sie können auch ein oder mehrere Cache-Verhalten so konfigurieren, dass sowohl HTTP als auch HTTPS zulässig sind, sodass HTTPS für einige Objekte CloudFront erforderlich ist, für andere jedoch nicht. Die Konfigurationsschritte hängen davon ab, welchen Domainnamen Sie im Objekt verwenden URLs:
+ Wenn Sie den Domainnamen verwenden, der Ihrer Distribution CloudFront zugewiesen wurde, z. B. d111111abcdef8.cloudfront.net, ändern Sie die Einstellung der **Viewer-Protokollrichtlinie** für ein oder mehrere Cache-Verhaltensweisen dahingehend, dass HTTPS-Kommunikation erforderlich ist. CloudFront Stellt in dieser Konfiguration das Zertifikat bereit. SSL/TLS
Informationen zum Ändern des Werts der **Viewer-Protokollrichtlinie** mithilfe der CloudFront Konsole finden Sie weiter unten in diesem Abschnitt.
Informationen darüber, wie Sie die CloudFront API verwenden können, um den Wert des `ViewerProtocolPolicy` Elements zu ändern, finden Sie [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)in der *Amazon CloudFront API-Referenz*.
+ Wenn Sie einen eigenen Domänennamen, z. B. beispiel.com, verwenden, müssen Sie mehrere CloudFront-Einstellungen ändern. Sie müssen auch ein von AWS Certificate Manager (ACM) bereitgestelltes SSL/TLS Zertifikat verwenden oder ein Zertifikat von einer externen Zertifizierungsstelle in ACM oder den IAM-Zertifikatsspeicher importieren. Weitere Informationen finden Sie unter [Verwenden von alternativen Domainnamen und HTTPS](using-https-alternate-domain-names.md).
**Anmerkung**
Wenn Sie sicherstellen möchten, dass die Objekte, von denen die Zuschauer empfangen, verschlüsselt CloudFront waren, als CloudFront sie von Ihrem Ursprung bezogen wurden, verwenden Sie immer HTTPS zwischen CloudFront und Ihrem Ursprung. Wenn Sie kürzlich zwischen CloudFront und Ihrem Ursprung von HTTP zu HTTPS gewechselt haben, empfehlen wir Ihnen, Objekte an CloudFront Edge-Standorten für ungültig zu erklären. CloudFront gibt ein Objekt an einen Viewer zurück, unabhängig davon, ob das vom Betrachter verwendete Protokoll (HTTP oder HTTPS) mit dem Protokoll übereinstimmt, CloudFront mit dem das Objekt abgerufen wurde. Weitere Informationen zum Entfernen oder Ersetzen von Objekten in einer Verteilung finden Sie unter [Hinzufügen, Entfernen oder Ersetzen von Inhalten, die von CloudFront verteilt werden](AddRemoveReplaceObjects.md).
## Erzwingen von HTTPS für Viewer
Gehen Sie wie folgt vor, um HTTPS zwischen Viewern und CloudFront für ein oder mehrere Cache-Verhaltensweisen vorzuschreiben.
**So konfigurieren Sie CloudFront , dass HTTPS zwischen Zuschauern erforderlich ist und CloudFront**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die CloudFront Konsole unter[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Wählen Sie im oberen Bereich der CloudFront Konsole die ID für die Distribution aus, die Sie aktualisieren möchten.
1. Wählen Sie auf der Registerkarte **Verhaltensweisen** das zu aktualisierende Cacheverhalten und anschließend **Bearbeiten** aus.
1. Geben Sie einen der folgenden Werte für **Viewer-Protokollrichtlinie** an:
**Redirect HTTP to HTTPS**
Viewer können beide Protokolle verwenden. HTTP `GET` und `HEAD` Anfragen werden automatisch zu HTTPS-Anfragen umgeleitet. CloudFront gibt den HTTP-Statuscode 301 (Dauerhaft verschoben) zusammen mit der neuen HTTPS-URL zurück. Der Betrachter sendet die Anfrage dann erneut, um die CloudFront HTTPS-URL zu verwenden.
Wenn Sie`POST`,, `PUT` `DELETE``OPTIONS`, oder `PATCH` über HTTP mit einem HTTP-zu-HTTPS-Cache-Verhalten und einer Anforderungsprotokollversion von HTTP 1.1 oder höher senden, CloudFront leitet die Anfrage an einen HTTPS-Standort mit dem HTTP-Statuscode 307 (Temporäre Umleitung) weiter. Dies gewährleistet, dass die Anforderung erneut unter Verwendung derselben Methode und derselben Nutzdaten an den neuen Speicherort gesendet wird.
Wenn Sie`POST`,, `PUT` `DELETE``OPTIONS`, oder `PATCH` Anfragen über HTTP an das HTTPS-Cache-Verhalten mit einer Anforderungsprotokollversion unter HTTP 1.1 senden, wird der HTTP-Statuscode 403 (Forbidden) CloudFront zurückgegeben.
Wenn ein Viewer eine HTTP-Anforderung veranlasst, die an eine HTTPS-Adresse umgeleitet wird, berechnet CloudFront Gebühren für beide Anforderungen. Bei der HTTP-Anfrage fallen die Gebühren nur für die Anfrage und für die Header an, die an den Betrachter CloudFront zurückgesendet werden. Bezüglich der HTTPS-Anforderung fallen Gebühren für die Anforderung sowie für die vom Ursprung zurückgegebenen Header und das Objekt an, das vom Ursprung zurückgegeben wird.
**Nur HTTPS**
Viewer können auf Ihre Inhalte nur zugreifen, wenn sie HTTPS verwenden. Wenn ein Betrachter statt einer HTTPS-Anfrage eine HTTP-Anfrage sendet, wird der HTTP-Statuscode 403 (Forbidden) CloudFront zurückgegeben und das Objekt nicht zurückgegeben.
1. Wählen Sie **Änderungen speichern ** aus.
1. Wiederholen Sie die Schritte 3 bis 5 für jedes weitere Cache-Verhalten, für das Sie HTTPS zwischen Zuschauern und benötigen CloudFront.
1. Vergewissern Sie sich, dass folgende Punkte erfüllt sind, bevor Sie die aktualisierte Konfiguration in einer Produktionsumgebung verwenden:
+ Das Pfadmuster eines jeden Cache-Verhaltens wird nur auf die Anforderungen angewendet, für die die Viewer HTTPS verwenden sollen.
+ Die Cache-Verhaltensweisen werden in der Reihenfolge aufgeführt, in der Sie sie auswerten CloudFront möchten. Weitere Informationen finden Sie unter [Pfadmuster](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
+ Die Cache-Verhaltensweisen leiten Anforderungen an die richtigen Ursprünge weiter.
# Erfordern Sie HTTPS für die Kommunikation zwischen CloudFront und Ihrem benutzerdefinierten Ursprung
Sie können HTTPS für die Kommunikation zwischen CloudFront und Ihrem Ursprung verlangen.
**Anmerkung**
Wenn Ihr Ursprung ein Amazon S3-Bucket ist, der als Website-Endpunkt konfiguriert ist, können Sie die Verwendung von HTTPS mit Ihrem Ursprung nicht konfigurieren CloudFront , da Amazon S3 HTTPS für Website-Endpunkte nicht unterstützt.
Um HTTPS zwischen CloudFront und Ihrem Ursprung zu verlangen, folgen Sie den Verfahren in diesem Thema, um Folgendes zu tun:
1. Ändern Sie in Ihrer Verteilung die Einstellung **Origin Protocol Policy (Ursprungsprotokollrichtlinie)** für den Ursprung
1. Installieren Sie ein SSL/TLS Zertifikat auf Ihrem Ursprungsserver (dies ist nicht erforderlich, wenn Sie einen Amazon S3 S3-Ursprung oder bestimmte andere AWS Ursprünge verwenden).
**Topics**
+ [Erzwingen von HTTPS für benutzerdefinierte Ursprünge](#using-https-cloudfront-to-origin-distribution-setting)
+ [Installieren Sie ein SSL/TLS Zertifikat auf Ihrem benutzerdefinierten Ursprung](#using-https-cloudfront-to-origin-certificate)
## Erzwingen von HTTPS für benutzerdefinierte Ursprünge
Das folgende Verfahren erklärt, wie Sie die Verwendung von HTTPS für die Kommunikation mit einem Elastic Load Balancing Load Balancer, einer EC2 Amazon-Instance oder einem anderen benutzerdefinierten Ursprung konfigurieren CloudFront . Informationen zur Verwendung der CloudFront API zur Aktualisierung einer Distribution finden Sie [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)in der *Amazon CloudFront API-Referenz*.
**Um CloudFront zu konfigurieren, dass HTTPS zwischen CloudFront und Ihrem benutzerdefinierten Ursprung erforderlich ist**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die CloudFront Konsole unter[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Wählen Sie im oberen Bereich der CloudFront Konsole die ID für die Distribution aus, die Sie aktualisieren möchten.
1. Wählen Sie auf der Registerkarte **Verhaltensweisen** den zu aktualisierenden Ursprung und anschließend **Bearbeiten** aus.
1. Aktualisieren Sie die folgenden Einstellungen:
**Ursprungsprotokollrichtlinien**
Ändern Sie die Einstellung von **Origin Protocol Policy** für die den betroffenen Ursprung in Ihrer Verteilung:
+ **Nur HTTPS** — CloudFront verwendet nur HTTPS für die Kommunikation mit Ihrem benutzerdefinierten Ursprung.
+ **Match Viewer** — CloudFront kommuniziert mit deinem benutzerdefinierten Absender über HTTP oder HTTPS, je nach Protokoll der Zuschaueranfrage. Wenn Sie beispielsweise **Match Viewer** für **Origin Protocol Policy** wählen und der Viewer HTTPS verwendet, um ein Objekt anzufordern CloudFront, verwendet er CloudFront auch HTTPS, um die Anfrage an Ihren Ursprung weiterzuleiten.
Wählen Sie **Match Viewer** nur dann, wenn Sie **Redirect HTTP to HTTPS** oder **HTTPS Only** für **Viewer Protocol Policy** auswählen.
CloudFront speichert das Objekt nur einmal, auch wenn Zuschauer Anfragen sowohl mit HTTP- als auch mit HTTPS-Protokollen stellen.
**Origin SSL Protocols**
Wählen Sie die **SSL-Protokolle** für den ausgewählten Ursprung in Ihrer Verteilung aus. Das SSLv3 Protokoll ist weniger sicher, daher empfehlen wir, dass du es SSLv3 nur dann auswählst, wenn dein Origin es nicht unterstützt TLSv1 oder später. Der TLSv1 Handshake ist sowohl abwärts- als auch vorwärtskompatibel mit SSLv3, TLSv1 .1 und höher jedoch nicht. Wenn Sie dies wünschen SSLv3, werden CloudFront *nur Handshake-Anfragen* gesendet SSLv3 .
1. Wählen Sie **Änderungen speichern ** aus.
1. Wiederholen Sie die Schritte 3 bis 5 für jeden weiteren Ursprung, für den Sie HTTPS zwischen CloudFront und Ihrem benutzerdefinierten Ursprung benötigen möchten.
1. Vergewissern Sie sich, dass folgende Punkte erfüllt sind, bevor Sie die aktualisierte Konfiguration in einer Produktionsumgebung verwenden:
+ Das Pfadmuster eines jeden Cache-Verhaltens wird nur auf die Anforderungen angewendet, für die die Viewer HTTPS verwenden sollen.
+ Die Cache-Verhaltensweisen werden in der Reihenfolge aufgeführt, in der Sie sie auswerten CloudFront möchten. Weitere Informationen finden Sie unter [Pfadmuster](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
+ Die Cache-Verhaltensweisen leiten Anforderungen an die Ursprünge weiter, deren **Origin Protocol Policy**-Einstellung Sie geändert haben.
## Installieren Sie ein SSL/TLS Zertifikat auf Ihrem benutzerdefinierten Ursprung
Sie können ein SSL/TLS Zertifikat aus den folgenden Quellen für Ihren benutzerdefinierten Ursprung verwenden:
+ Wenn Ihr Ursprung ein Elastic Load Balancing-Load Balancer ist, können Sie ein Zertifikat verwenden, das von AWS Certificate Manager (ACM) bereitgestellt wird. Sie können auch ein Zertifikat verwenden, das von einer vertrauenswürdigen Zertifizierungsstelle signiert und in ACM importiert wurde.
+ Für andere Quellen als Elastic Load Balancing Load Balancer müssen Sie ein Zertifikat verwenden, das von einer vertrauenswürdigen Zertifizierungsstelle (CA) eines Drittanbieters signiert wurde, z. B. Comodo oder DigiCert Symantec.
Das vom Ursprungs zurückgegebene Zertifikat muss einen der folgenden Domänennamen enthalten:
+ Der Domainname im Feld **Origin-Domain des Ursprungs** (das `DomainName` Feld in der CloudFront API).
+ Den Domänennamen im `Host`-Header, wenn das Cache-Verhalten so konfiguriert ist, dass der `Host`-Header zum Ursprung weiterleitet.
Wenn HTTPS für die Kommunikation mit Ihrem Ursprungsserver CloudFront verwendet wird, CloudFront wird überprüft, ob das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wurde. CloudFront unterstützt dieselben Zertifizierungsstellen wie Mozilla. Die aktuelle Liste finden Sie unter [Mozilla-Liste der CA-Zertifikate](https://wiki.mozilla.org/CA/Included_Certificates). Sie können kein selbstsigniertes Zertifikat für die HTTPS-Kommunikation zwischen CloudFront und Ihrem Ursprung verwenden.
**Wichtig**
Wenn der Ursprungsserver ein abgelaufenes Zertifikat, ein ungültiges Zertifikat oder ein selbstsigniertes Zertifikat zurückgibt oder wenn der Ursprungsserver die Zertifikatskette in der falschen Reihenfolge zurückgibt, CloudFront bricht er die TCP-Verbindung ab, gibt den HTTP-Statuscode 502 (Bad Gateway) an den Viewer zurück und setzt den `X-Cache` Header auf. `Error from cloudfront` Außerdem wird die TCP-Verbindung unterbrochen, wenn die gesamte Zertifikatskette, einschließlich des Zwischenzertifikats CloudFront , nicht vorhanden ist.
# Erfordern Sie HTTPS für die Kommunikation zwischen CloudFront und Ihrem Amazon S3 S3-Ursprung
Wenn Ihr Ursprung ein Amazon S3 S3-Bucket ist, CloudFront hängen Ihre Optionen für die Verwendung von HTTPS für die Kommunikation mit davon ab, wie Sie den Bucket verwenden. Wenn Ihr Amazon S3-Bucket als Website-Endpunkt konfiguriert ist, können Sie die Verwendung von HTTPS für die Kommunikation mit Ihrem Ursprung nicht konfigurieren CloudFront , da Amazon S3 in dieser Konfiguration keine HTTPS-Verbindungen unterstützt.
Wenn es sich bei Ihrem Ursprung um einen Amazon S3 S3-Bucket handelt, der HTTPS-Kommunikation unterstützt, CloudFront leitet er Anfragen an S3 weiter. Dabei wird das Protokoll verwendet, mit dem die Zuschauer die Anfragen eingereicht haben. Die Standardeinstellung von [Protokoll (nur benutzerdefinierte Ursprünge)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy) ist **Match Viewer (An Betrachter anpassen)** und kann nicht geändert werden. Wenn Sie jedoch Origin Access Control (OAC) für Ihren Amazon S3-Ursprung aktivieren, hängt die zwischen Amazon S3 CloudFront und Amazon S3 verwendete Kommunikation von Ihren Einstellungen ab. Weitere Informationen finden Sie unter [Erstellen einer neuen Ursprungszugriffssteuerung](private-content-restricting-access-to-s3.md#create-oac-overview-s3).
Wenn Sie HTTPS für die Kommunikation zwischen Amazon S3 CloudFront und Amazon S3 benötigen möchten, müssen Sie den Wert der **Viewer-Protokollrichtlinie** auf „**HTTP zu HTTPS umleiten**“ oder „**Nur HTTPS**“ ändern. Das Verfahren weiter unten in diesem Abschnitt erklärt, wie Sie die **Viewer-Protokollrichtlinie** mithilfe der CloudFront Konsole ändern. Informationen zur Verwendung der CloudFront API zur Aktualisierung des `ViewerProtocolPolicy` Elements für eine Distribution finden Sie [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)in der *Amazon CloudFront API-Referenz*.
Wenn Sie HTTPS mit einem Amazon S3-Bucket verwenden, der HTTPS-Kommunikation unterstützt, stellt Amazon S3 das SSL/TLS Zertifikat bereit, sodass Sie dies nicht tun müssen.
## Erzwingen von HTTPS für einen Amazon-S3-Ursprung
Das folgende Verfahren zeigt Ihnen, wie Sie so konfigurieren CloudFront , dass HTTPS für Ihren Amazon S3 S3-Ursprung erforderlich ist.
**So konfigurieren Sie CloudFront , dass HTTPS für Ihren Amazon S3 S3-Ursprung erforderlich ist**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die CloudFront Konsole unter[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Wählen Sie im oberen Bereich der CloudFront Konsole die ID für die Distribution aus, die Sie aktualisieren möchten.
1. Wählen Sie auf der Registerkarte **Behaviors** das zu aktualisierende Cache-Verhalten und anschließend **Edit** aus.
1. Geben Sie einen der folgenden Werte für **Viewer Protocol Policy** an:
**Redirect HTTP to HTTPS**
Zuschauer können beide Protokolle verwenden, HTTP-Anfragen werden jedoch automatisch zu HTTPS-Anfragen umgeleitet. CloudFront gibt den HTTP-Statuscode 301 (Dauerhaft verschoben) zusammen mit der neuen HTTPS-URL zurück. Der Betrachter sendet die Anfrage dann erneut, um die CloudFront HTTPS-URL zu verwenden.
CloudFront leitet`DELETE`,, `OPTIONS` `PATCH``POST`, oder `PUT` Anfragen nicht von HTTP zu HTTPS weiter. Wenn Sie ein Cache-Verhalten so konfigurieren, dass es zu HTTPS umleitet, CloudFront reagiert auf HTTP- `DELETE` `OPTIONS``PATCH`,`POST`,, oder `PUT` Anfragen für dieses Cache-Verhalten mit dem HTTP-Statuscode 403 (Verboten).
Wenn ein Viewer eine HTTP-Anforderung veranlasst, die an eine HTTPS-Adresse umgeleitet wird, berechnet CloudFront Gebühren für beide Anforderungen. Bei der HTTP-Anfrage fallen die Gebühren nur für die Anfrage und für die Header an, die an den Betrachter CloudFront zurückgesendet werden. Bezüglich der HTTPS-Anforderung fallen Gebühren für die Anforderung sowie für die vom Ursprung zurückgegebenen Header und das Objekt an, das vom Ursprung zurückgegeben wird.
**HTTPS Only**
Viewer können auf Ihre Inhalte nur zugreifen, wenn sie HTTPS verwenden. Wenn ein Betrachter statt einer HTTPS-Anfrage eine HTTP-Anfrage sendet, wird der HTTP-Statuscode 403 (Forbidden) CloudFront zurückgegeben und das Objekt nicht zurückgegeben.
1. Wählen Sie **Yes, Edit** aus.
1. Wiederholen Sie die Schritte 3 bis 5 für jedes weitere Cache-Verhalten, für das Sie HTTPS zwischen Zuschauern und CloudFront CloudFront und zwischen S3 benötigen möchten.
1. Vergewissern Sie sich, dass folgende Punkte erfüllt sind, bevor Sie die aktualisierte Konfiguration in einer Produktionsumgebung verwenden:
+ Das Pfadmuster eines jeden Cache-Verhaltens wird nur auf die Anforderungen angewendet, für die die Viewer HTTPS verwenden sollen.
+ Die Cache-Verhaltensweisen werden in der Reihenfolge aufgeführt, in der Sie sie auswerten CloudFront möchten. Weitere Informationen finden Sie unter [Pfadmuster](DownloadDistValuesCacheBehavior.md#DownloadDistValuesPathPattern).
+ Die Cache-Verhaltensweisen leiten Anforderungen an die richtigen Ursprünge weiter.
# Unterstützte Protokolle und Chiffren zwischen Zuschauern und CloudFront
Wenn Sie [HTTPS zwischen Zuschauern und Ihrer CloudFront Distribution benötigen](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy), müssen Sie eine [Sicherheitsrichtlinie](DownloadDistValuesGeneral.md#DownloadDistValues-security-policy) wählen, die die folgenden Einstellungen festlegt:
+ Das SSL/TLS Mindestprotokoll, das für die Kommunikation mit Zuschauern CloudFront verwendet wird.
+ Die Chiffren, mit denen die Kommunikation mit Zuschauern verschlüsselt werden CloudFront kann.
Um eine Sicherheitsrichtlinie auszuwählen, geben Sie den anwendbaren Wert für [Sicherheitsrichtlinie (SSL/TLS-Mindestversion)](DownloadDistValuesGeneral.md#DownloadDistValues-security-policy) an. In der folgenden Tabelle sind die Protokolle und Chiffren aufgeführt, die für jede Sicherheitsrichtlinie verwendet CloudFront werden können.
Ein Betrachter muss mindestens eine der unterstützten Verschlüsselungen unterstützen, um eine HTTPS-Verbindung herzustellen. CloudFront CloudFront wählt aus den Verschlüsselungen, die der Betrachter unterstützt, eine Chiffre in der aufgelisteten Reihenfolge aus. Siehe auch [OpenSSL-, s2n- und RFC-Verschlüsselungsnamen](#secure-connections-openssl-rfc-cipher-names).
| | Sicherheitsrichtlinie | | SSLv3 | TLSv1 | TLSv1\$12016 | TLSv1.1\$12016 | TLSv1.2\$12018 | TLSv1.2\$12019 | TLSv1.2\$12021 | TLSv1.2\$12025 | TLSv1.3\$12025 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Unterstützte Protokolle SSL/TLS |
| TLSv13. | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLSv12. | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | |
| TLSv11. | ♦ | ♦ | ♦ | ♦ | | | | | |
| TLSv1 | ♦ | ♦ | ♦ | | | | | | |
| SSLv3 | ♦ | | | | | | | | |
| Unterstützte TLSv1 3.3-Chiffren |
| TLS\$1AES\$1128\$1GCM\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1AES\$1256\$1GCM\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1 0\$1 05\$1 CHACHA2 POLY13 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | | ♦ |
| Unterstützte ECDSA-Verschlüsselungen |
| ECDHE-ECDSA- -GCM- AES128 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | |
| ECDHE-ECDSA- - AES128 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | | | |
| ECDHE-ECDSA- -SHA AES128 | ♦ | ♦ | ♦ | ♦ | | | | | |
| ECDHE-ECDSA- -GCM- AES256 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | |
| ECDHE-ECDSA- 0 CHACHA2 - 05 POLY13 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | | |
| ECDHE-ECDSA- AES256 - SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | | | |
| ECDHE-ECDSA- -SHA AES256 | ♦ | ♦ | ♦ | ♦ | | | | | |
| Unterstützte RSA-Verschlüsselungen |
| ECDHE-RSA- -GCM- AES128 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | |
| ECDHE-RSA- AES128 - SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | | | |
| ECDHE-RSA- AES128 -SHA | ♦ | ♦ | ♦ | ♦ | | | | | |
| ECDHE-RSA- AES256 -GCM- SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | |
| ECDHE-RSA- CHACHA2 0- 05 POLY13 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | | |
| ECDHE-RSA AES256 - - SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | | | |
| ECDHE-RSA- AES256 -SHA | ♦ | ♦ | ♦ | ♦ | | | | | |
| AES128-GCM- SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | | | | |
| AES256-GCM- SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | | | | |
| AES128-SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | | | | |
| AES256-SCHA | ♦ | ♦ | ♦ | ♦ | | | | | |
| AES128-SCHA | ♦ | ♦ | ♦ | ♦ | | | | | |
| DES-SHA CBC3 | ♦ | ♦ | | | | | | | |
| RC4-MD5 | ♦ | | | | | | | | |
## OpenSSL-, s2n- und RFC-Verschlüsselungsnamen
OpenSSL und [s2n](https://github.com/awslabs/s2n) verwenden für Chiffren andere Namen als die TLS-Standards verwenden ([RFC 2246](https://tools.ietf.org/html/rfc2246), [RFC 4346](https://tools.ietf.org/html/rfc4346), [RFC 5246](https://tools.ietf.org/html/rfc5246), und [RFC 8446](https://tools.ietf.org/html/rfc8446)). Die folgende Tabelle ordnet den OpenSSL-Namen und s2n Namen den RFC-Namen für jedes Verschlüsselungsverfahren zu.
CloudFront unterstützt sowohl den klassischen als auch den quantensicheren Schlüsselaustausch. Unterstützt für den klassischen Schlüsselaustausch mit elliptischen Kurven Folgendes: CloudFront
+ `prime256v1`
+ `X25519`
+ `secp384r1`
Unterstützt für quantensicheren Schlüsselaustausch Folgendes: CloudFront
+ `X25519MLKEM768`
+ `SecP256r1MLKEM768`
**Anmerkung**
Der quantensichere Schlüsselaustausch wird nur mit TLS 1.3 unterstützt. TLS 1.2 und frühere Versionen unterstützen keinen quantensicheren Schlüsselaustausch.
Weitere Informationen finden Sie unter den folgenden Themen:
+ [Post-Quanten-Kryptographie](https://aws.amazon.com/security/post-quantum-cryptography/)
+ [Kryptographiealgorithmen und AWS-Services](https://docs.aws.amazon.com/prescriptive-guidance/latest/encryption-best-practices/aws-cryptography-services.html#algorithms)
+ [Hybrider Schlüsselaustausch in TLS 1.3](https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/)
Weitere Informationen zu den Zertifikatsanforderungen für finden Sie CloudFront unter[Anforderungen für die Verwendung von SSL/TLS Zertifikaten mit CloudFront](cnames-and-https-requirements.md).
| OpenSSL- und s2n-Chiffrenname | RFC-Verschlüsselungsname |
| --- | --- |
| Unterstützte TLSv1 3.3-Chiffren |
| TLS\$1AES\$1128\$1GCM\$1 SHA256 | TLS AES 128 GCM SHA256 |
| TLS\$1AES\$1256\$1GCM\$1 SHA384 | TLS\$1AES\$1256\$1GCM\$1 SHA384 |
| TLS\$1 0\$1 05\$1 CHACHA2 POLY13 SHA256 | TLS\$1 CHACHA2 0\$1 POLY13 05\$1 SHA256 |
| Unterstützte ECDSA-Verschlüsselungen |
| ECDHE-ECDSA- -GCM- AES128 SHA256 | TLS\$1ECDHE\$1ECDSA\$1MIT\$1AES\$1128\$1GCM\$1 SHA256 |
| ECDHE-ECDSA- - AES128 SHA256 | TLS\$1ECDHE\$1ECDSA\$1MIT\$1AES\$1128\$1CBC\$1 SHA256 |
| ECDHE-ECDSA-SHA AES128 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1SHA |
| ECDHE-ECDSA- -GCM- AES256 SHA384 | TLS\$1ECDHE\$1ECDSA\$1MIT\$1AES\$1256\$1GCM\$1 SHA384 |
| ECDHE-ECDSA- 0- 05 CHACHA2 POLY13 | TLS\$1ECDHE\$1ECDSA\$1MIT\$1 CHACHA2 POLY13 0\$1 05\$1 SHA256 |
| ECDHE-ECDSA- - AES256 SHA384 | TLS\$1ECDHE\$1ECDSA\$1MIT\$1AES\$1256\$1CBC\$1 SHA384 |
| ECDHE-ECDSA-SHA AES256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA |
| Unterstützte RSA-Verschlüsselungen |
| ECDHE-RSA- -GCM- AES128 SHA256 | TLS\$1ECDHE\$1RSA\$1MIT\$1AES\$1128\$1GCM\$1 SHA256 |
| ECDHE-RSA- - AES128 SHA256 | TLS\$1ECDHE\$1RSA\$1MIT\$1AES\$1128\$1CBC\$1 SHA256 |
| ECDHE-RSA-SHA AES128 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA |
| ECDHE-RSA- AES256 -GCM- SHA384 | TLS\$1ECDHE\$1RSA\$1MIT\$1AES\$1256\$1GCM\$1 SHA384 |
| ECDHE-RSA- 0- 05 CHACHA2 POLY13 | CHACHA2TLS\$1ECDHE\$1RSA\$1MIT\$1 POLY13 0\$1 05\$1 SHA256 |
| ECDHE-RSA- - AES256 SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1 SHA384 |
| ECDHE-RSA-SHA AES256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA |
| AES128-GCM- SHA256 | TLS\$1RSA\$1MIT\$1AES\$1128\$1GCM\$1 SHA256 |
| AES256-GCM- SHA384 | TLS\$1RSA\$1MIT\$1AES\$1256\$1GCM\$1 SHA384 |
| AES128-SHA256 | TLS\$1RSA\$1MIT\$1AES\$1128\$1CBC\$1 SHA256 |
| AES256-SCHA | TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA |
| AES128-SCHA | TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA |
| DES-SHA CBC3 | TLS\$1RSA\$1WITH\$13DES\$1EDE\$1CBC\$1SHA |
| RC4-MD5 | TLS\$1RSA\$1MIT\$1 \$1128\$1 RC4 MD5 |
## Unterstützte Signaturschemas zwischen Zuschauern und CloudFront
CloudFront unterstützt die folgenden Signaturschemas für Verbindungen zwischen Zuschauern undCloudFront.
| | Sicherheitsrichtlinie | Signaturschemata | SSLv3 | TLSv1 | TLSv1\$12016 | TLSv1.1\$12016 | TLSv1.2\$12018 | TLSv1.2\$12019 | TLSv1.2\$12021 | TLSv1.2\$12025 | TLSv1.3\$12025 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1PSS\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1PSS\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1PSS\$1 SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1RSAE\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1RSAE\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1PSS\$1RSAE\$1 SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| PKCS1TLS\$1SIGNATURE\$1SCHEMA\$1RSA\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 PKCS1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 PKCS1 SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 PKCS1 SHA224 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | | |
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA512 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA224 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | | |
| SECP256TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 R1\$1 SHA256 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| SECP384TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 R1\$1 SHA384 | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ | ♦ |
| TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 PKCS1 SHA1 | ♦ | ♦ | ♦ | ♦ | | | | | |
| TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA1 | ♦ | ♦ | ♦ | ♦ | | | | | |
# Unterstützte Protokolle und Chiffren zwischen und dem Ursprung CloudFront
Wenn Sie [HTTPS zwischen CloudFront und Ihrem Ursprung](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesOriginProtocolPolicy) angeben, können Sie entscheiden, [welches SSL/TLS Protokoll für die sichere Verbindung zulässig](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesOriginSSLProtocols) ist, und Sie CloudFront können eine Verbindung zum Ursprung herstellen, indem Sie eine der in der folgenden Tabelle aufgeführten ECDSA- oder RSA-Chiffren verwenden. Ihr Ursprung muss mindestens eine dieser Chiffren unterstützen, um eine HTTPS-Verbindung CloudFront zu Ihrem Ursprung herzustellen.
OpenSSL und [s2n](https://github.com/awslabs/s2n) verwenden für Chiffren andere Namen als die TLS-Standards verwenden ([RFC 2246](https://tools.ietf.org/html/rfc2246), [RFC 4346](https://tools.ietf.org/html/rfc4346), [RFC 5246](https://tools.ietf.org/html/rfc5246), und [RFC 8446](https://tools.ietf.org/html/rfc8446)). Die folgende Tabelle beinhaltet den OpenSSL-Namen und s2n Namen den RFC-Namen für jedes Verschlüsselungsverfahren.
CloudFront Unterstützt für Chiffren mit elliptischen Kurven für den Schlüsselaustausch die folgenden elliptischen Kurven:
+ prime256v1
+ secp384r1
+ X25519
| OpenSSL- und s2n-Chiffrenname | RFC-Verschlüsselungsname |
| --- | --- |
| Unterstützte ECDSA-Verschlüsselungen |
| ECDHE-ECDSA- -GCM- AES256 SHA384 | TLS\$1ECDHE\$1ECDSA\$1MIT\$1AES\$1256\$1GCM\$1 SHA384 |
| ECDHE-ECDSA- - AES256 SHA384 | TLS\$1ECDHE\$1ECDSA\$1MIT\$1AES\$1256\$1CBC\$1 SHA384 |
| ECDHE-ECDSA-SHA AES256 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1256\$1CBC\$1SHA |
| ECDHE-ECDSA- -GCM- AES128 SHA256 | TLS\$1ECDHE\$1ECDSA\$1MIT\$1AES\$1128\$1GCM\$1 SHA256 |
| ECDHE-ECDSA- - AES128 SHA256 | TLS\$1ECDHE\$1ECDSA\$1MIT\$1AES\$1128\$1CBC\$1 SHA256 |
| ECDHE-ECDSA-SHA AES128 | TLS\$1ECDHE\$1ECDSA\$1WITH\$1AES\$1128\$1CBC\$1SHA |
| Unterstützte RSA-Verschlüsselungen |
| ECDHE-RSA- -GCM- AES256 SHA384 | TLS\$1ECDHE\$1RSA\$1MIT\$1AES\$1256\$1GCM\$1 SHA384 |
| ECDHE-RSA- - AES256 SHA384 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1 SHA384 |
| ECDHE-RSA-SHA AES256 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA |
| ECDHE-RSA- AES128 -GCM- SHA256 | TLS\$1ECDHE\$1RSA\$1MIT\$1AES\$1128\$1GCM\$1 SHA256 |
| ECDHE-RSA- - AES128 SHA256 | TLS\$1ECDHE\$1RSA\$1MIT\$1AES\$1128\$1CBC\$1 SHA256 |
| ECDHE-RSA-SHA AES128 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA |
| AES256-SCHA | TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA |
| AES128-SCHA | TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA |
| DES-SHA CBC3 | TLS\$1RSA\$1WITH\$13DES\$1EDE\$1CBC\$1SHA |
| RC4-MD5 | TLS\$1RSA\$1MIT\$1 \$1128\$1 RC4 MD5 |
**Unterstützte Signaturschemas zwischen und dem Ursprung CloudFront **
CloudFront unterstützt die folgenden Signaturschemas für Verbindungen zwischen CloudFront und dem Ursprung.
+ TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 PKCS1 SHA256
+ TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 PKCS1 SHA384
+ TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 PKCS1 SHA512
+ TLS\$1SIGNATURE\$1SCHEME\$1RSA\$1 \$1 PKCS1 SHA224
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA256
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA384
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA512
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA224
+ PKCS1TLS\$1SIGNATURE\$1SCHEMA\$1RSA\$1 SHA1
+ TLS\$1SIGNATURE\$1SCHEME\$1ECDSA\$1 SHA1