Einen Inhaltsendpunkt mit HTTPS absichern

Einführung

Der Inhaltsendpunkt funktioniert, doch Kunden sollen Inhalte über eine verschlüsselte Verbindung mit geprüfter Serveridentität lesen. Verbinde ein vorbereitetes ACM-Zertifikat mit einem alternativen CloudFront-Namen, verlange HTTPS und teste die echte Seite sowie Zertifikatsvertrauen und Namen.

Schließe zuerst das Labor zur privaten S3-Bereitstellung ab. Diese unabhängige VM liefert eine neue private Ursprungsverbindung, ein importiertes Zertifikat für content.labex-n04.test und den öffentlichen Vertrauensanker practice-ca.pem. Das Zertifikat ist noch nicht mit der Distribution verbunden. Beobachte den Zustand oben in AWS View und nutze unten Terminal. Ein persönliches AWS-Konto oder eine gekaufte Domain ist nicht erforderlich.

Das Übungszertifikat wurde von einer vorbereiteten privaten Zertifizierungsstelle signiert. Vertraue ihrer öffentlichen CA-Datei für einen einzelnen Befehl, ohne den systemweiten Vertrauensspeicher zu ändern. Eine öffentliche CloudFront-Website benötigt ein öffentlich vertrauenswürdiges Zertifikat. Hier übst du die Zuordnung und echte TLS-Prüfungen ohne öffentliche Domainregistrierung oder Zertifikatsausstellung.

Zertifizierungsziele

Laborübersicht

Zertifikat zuordnen und HTTPS verlangen

In diesem Schritt verbindest du vorbereitetes Zertifikat und alternativen Namen mit der Distribution und verlangst verschlüsselte Viewer-Anfragen.

TLS verschlüsselt eine Verbindung und ermöglicht die Prüfung der Serveridentität. Ein Zertifikat enthält Namen und einen öffentlichen Schlüssel, signiert von einer Zertifizierungsstelle (CA). ACM, AWS Certificate Manager, verwaltet Zertifikate für AWS-Dienste. Ein Zertifikat in ACM wird nicht automatisch einer Distribution zugeordnet.

Ermittle die vorbereiteten Ressourcen. $(...) speichert Befehlsausgaben in Shell-Variablen; --query wählt die passende Ressource und --output text macht ihre ID als Argument nutzbar. Halte Terminal geöffnet:

cd /home/labex/project
HOST_NAME=content.labex-n04.test
DIST_ID=$(aws cloudfront list-distributions \
  --query "DistributionList.Items[?Comment=='labex-n04:private-content'].Id | [0]" \
  --output text)
CERT_ARN=$(aws acm list-certificates \
  --query "CertificateSummaryList[?DomainName=='content.labex-n04.test'].CertificateArn | [0]" \
  --output text)
aws acm describe-certificate \
  --certificate-arn "$CERT_ARN" \
  --query 'Certificate.{Name:DomainName,Names:SubjectAlternativeNames,Status:Status}'

Erwarte ISSUED und den Übungsnamen unter Names. Die ARN bezeichnet Konto und Region. ACM-Viewer-Zertifikate für CloudFront müssen in us-east-1 liegen; die vorbereitete ARN verwendet diese Region. Das Zertifikat muss den zugeordneten alternativen Namen abdecken.

Lies aktuelle Distributionskonfiguration und ETag, das Versionstoken für ein Update. > speichert die Ausgabe in einer Datei:

aws cloudfront get-distribution-config \
  --id "$DIST_ID" \
  --query DistributionConfig > current-config.json
ETAG=$(aws cloudfront get-distribution-config \
  --id "$DIST_ID" \
  --query ETag \
  --output text)

Ein alternativer Domainname, auch Alias, lässt die Distribution den Inhaltsnamen erkennen. SNI, Server Name Indication, sendet diesen Namen beim TLS-Aufbau zur Zertifikatsauswahl. Die Viewer-Protokollrichtlinie steuert HTTP und HTTPS getrennt von der S3-Ursprungsberechtigung.

jq bearbeitet JSON und erhält die anderen Einstellungen. --arg übergibt erfasste Werte als JSON-Zeichenfolgen. Die |-Operatoren im zitierten Ausdruck wenden nacheinander Alias, benutzerdefinierte Zertifikatseinstellungen und https-only-Zugriff an. Die ausgewählte Sicherheitsrichtlinie verlangt TLS 1.2 oder neuer:

jq --arg host "$HOST_NAME" --arg cert "$CERT_ARN"   '.Aliases = {Quantity: 1, Items: [$host]} |
   .ViewerCertificate = {CloudFrontDefaultCertificate: false,
     ACMCertificateArn: $cert, SSLSupportMethod: "sni-only",
     MinimumProtocolVersion: "TLSv1.2_2021"} |
   .DefaultCacheBehavior.ViewerProtocolPolicy = "https-only"'   current-config.json > https-config.json
aws cloudfront update-distribution \
  --id "$DIST_ID" \
  --if-match "$ETAG" \
  --distribution-config file://https-config.json
aws cloudfront wait distribution-deployed \
  --id "$DIST_ID"

Prüfe gespeicherte Einstellungen, bevor du die Verbindung testest:

aws cloudfront get-distribution-config \
  --id "$DIST_ID" \
  --query 'DistributionConfig.{Names:Aliases.Items,Certificate:ViewerCertificate.ACMCertificateArn,Protocol:DefaultCacheBehavior.ViewerProtocolPolicy}'

Erwarte genauen Übungsnamen, deine Zertifikats-ARN und https-only. AWS View zeigt Alias und zugeordnetes ACM-Zertifikat. Die native Konfiguration ist bereit; im nächsten Schritt beweist du eine echte verschlüsselte Anfrage. Führe die Zuordnungsprüfung aus.

Verschlüsselten Inhalt und Zertifikat prüfen

In diesem Schritt liest du die Seite über vertrauenswürdiges HTTPS, beobachtest abgewiesenen Klartextzugriff und unterscheidest Zertifikatsvertrauen von Hostnamenprüfung.

curl --cacert practice-ca.pem vertraut der vorbereiteten öffentlichen CA nur für diesen Befehl. --resolve verbindet den genauen Namen und Port mit dieser VM und erhält den Namen für SNI und Zertifikatsprüfung. Es registriert keine öffentliche Domain und ändert kein System-DNS. Der vorbereitete HTTPS-Viewer verwendet Port 8443:

curl --fail --include --noproxy '*' --cacert practice-ca.pem   --resolve "${HOST_NAME}:8443:127.0.0.1"   "https://${HOST_NAME}:8443/index.html"

Erwarte HTTP 200 und Release one. Der Client hat echtes TLS aufgebaut, vertrauenswürdigen Aussteller und Namen geprüft und die tatsächliche S3-Seite erhalten. Das beweist mehr als eine gespeicherte ARN.

Teste den Klartext-Viewer und anonymen direkten Ursprungszugriff:

curl --noproxy '*' --output /dev/null   --resolve "${HOST_NAME}:8082:127.0.0.1"   --write-out 'Plaintext viewer: HTTP %{http_code}\n'   "http://${HOST_NAME}:8082/index.html"
curl --noproxy '*' --output /dev/null   --write-out 'Anonymous origin: HTTP %{http_code}\n'   http://127.0.0.1:5000/labex-n04-content/index.html

Beide müssen HTTP 403 liefern. Viewer-HTTPS macht den S3-Bucket nicht öffentlich; es sind getrennte Schutzmaßnahmen.

Lasse jetzt die CA-Datei weg, um Vertrauen zu testen. Dieser Befehl soll absichtlich fehlschlagen:

curl --fail --noproxy '*'   --resolve "${HOST_NAME}:8443:127.0.0.1"   "https://${HOST_NAME}:8443/index.html"

Erwarte einen Zertifikatsfehler, üblicherweise curl-Fehler 60: der Standard-Vertrauensspeicher vertraut dieser privaten CA nicht. Fahre nach dem erwarteten Fehler fort. Die erfolgreiche Anfrage wählte den richtigen Vertrauensanker; deaktivierte Prüfung würde den geübten Schutz entfernen.

openssl s_client trennt den SNI-Auswahlnamen vom zu prüfenden Namen. Sende richtiges SNI und vertraue der CA, verlange aber einen absichtlich falschen Prüfnamen. -verify_return_error stoppt bei Prüfungsfehlern; < /dev/null verhindert interaktive Eingaben:

openssl s_client -connect 127.0.0.1:8443   -servername "$HOST_NAME" -CAfile practice-ca.pem   -verify_hostname wrong.labex-n04.test   -verify_return_error < /dev/null

Erwarte hostname mismatch und eine fehlgeschlagene Prüfung. Vertrauen in den Aussteller reicht nicht: das Zertifikat muss auch die angeforderte Identität abdecken. AWS View bewahrt das echte verschlüsselte Ergebnis und den abgewiesenen Klartextzugriff. Führe die HTTPS-Prüfung aus.

Nur deine Bereitstellungsressourcen entfernen

In diesem Schritt deaktivierst und löschst du zuerst die Distribution, dann OAC, S3-Inhalt und das vorbereitete Zertifikat. Behalte den Referenz-Bucket unverändert.

CloudFront verwendet ETag als Versionstoken. Hole aktuelle Konfiguration und ETag, statt das Token zu raten. Erfasse zuerst den genauen OAC am Ursprung:

OAC_ID=$(aws cloudfront get-distribution-config \
  --id "$DIST_ID" \
  --query 'DistributionConfig.Origins.Items[0].OriginAccessControlId' \
  --output text)

Speichere die Konfiguration und erfasse ihren ETag:

aws cloudfront get-distribution-config \
  --id "$DIST_ID" \
  --query DistributionConfig \
  --output json > distribution-current.json
DIST_ETAG=$(aws cloudfront get-distribution-config \
  --id "$DIST_ID" \
  --query ETag \
  --output text)

In der aktuellen Konfiguration ist Enabled der Distribution das einzige gleichnamige Attribut mit Wert true. Die normale sed-Ersetzung erstellt eine deaktivierte Kopie und erhält den Ursprung:

sed 's/"Enabled": true/"Enabled": false/' distribution-current.json > distribution-disabled.json
aws cloudfront update-distribution \
  --id "$DIST_ID" \
  --if-match "$DIST_ETAG" \
  --distribution-config file://distribution-disabled.json

Warte auf Bereitstellung der deaktivierten Konfiguration. AWS-Änderungen können Zeit benötigen; hier wird keine weltweite Bereitstellungsverzögerung gemessen:

aws cloudfront wait distribution-deployed \
  --id "$DIST_ID"

Das Update ändert den ETag. Lies das neueste Token, bevor du die deaktivierte Distribution löschst:

DIST_ETAG=$(aws cloudfront get-distribution-config \
  --id "$DIST_ID" \
  --query ETag \
  --output text)
aws cloudfront delete-distribution \
  --id "$DIST_ID" \
  --if-match "$DIST_ETAG"

Lösche OAC mit seinem eigenen ETag. Distributions-ID und OAC-ID bezeichnen verschiedene Ressourcen:

OAC_ETAG=$(aws cloudfront get-origin-access-control \
  --id "$OAC_ID" \
  --query ETag \
  --output text)
aws cloudfront delete-origin-access-control \
  --id "$OAC_ID" \
  --if-match "$OAC_ETAG"

Lösche nur Inhaltsobjekt und Bucket dieses Labors:

aws s3api delete-object \
  --bucket labex-n04-content \
  --key index.html
aws s3api delete-bucket \
  --bucket labex-n04-content
aws s3api list-buckets \
  --query 'Buckets[].Name'

Lösche nach der Distribution nur das vorbereitete Zertifikat mit der zuvor ausgewählten ARN. Das entfernt die ACM-Ressource; die öffentliche CA-Datei darf als unabhängige lokale Vorlage bleiben:

aws acm delete-certificate \
  --certificate-arn "$CERT_ARN"
aws acm list-certificates \
  --query 'CertificateSummaryList[].CertificateArn'

Es darf kein Zertifikat des Labors verbleiben. Der Referenz-Bucket bleibt, der Inhalts-Bucket muss fehlen. AWS View sollte keine Inhaltsdistribution und nur die Referenz zeigen. Führe die Bereinigungsprüfung aus. Eine fehlgeschlagene API-Anfrage beweist keine Löschung.

Zusammenfassung

Du hast ACM-Zertifikat und alternativen Namen mit CloudFront verbunden, HTTPS verlangt und echte Inhalte über geprüftes TLS gelesen. Du hast vertrauenswürdigen Aussteller, passenden Hostnamen, Viewer-Verschlüsselung und privaten Ursprungszugriff unterschieden. Klartext wurde abgewiesen; Prüfungen mit nicht vertrauenswürdigem Aussteller und falschem Namen schlugen fehl. Du hast nur eigene Ressourcen und das Laborzertifikat entfernt und die unabhängige Referenz erhalten.