
Ich verschiebe example.com von einem externen (nicht Google) Hosting-Anbieter zu GCP.
Beim Einrichten des Load Balancers ist mir aufgefallen, dass ich example.com auf den Load Balancer verweisen muss, damit das von Google verwaltete Zertifikat validiert wird.
Ich soll einfach den A-Eintrag von example.com in die (statische) IP des neuen Load Balancers ändern – dann wird es validiert.
Das Problem besteht darin, dass ich bereits eine Menge Verkehr auf example.com habe. Anfragen, die erfolgen, nachdem example.com mit der Anzeige auf den Load Balancer begonnen hat, aber bevor das Zertifikat validiert wurde, führen zu SSL-Fehlern und sehr unzufriedenen Benutzern.
Hat das jemand gelöst? Ich weiß, dass es Möglichkeiten gibt,vermeiden Sie Ausfallzeiten, wennDrehenZertifikate, aber es muss doch eine Möglichkeit geben, große Sites ohne Ausfallzeiten zu migrieren?
Antwort1
Die anderen Antworten sind sehr gut, aber ich war sehr motiviert, einen Weg zu finden, auf einen GCP-Load Balancer zu migrieren, ohne Ausfallzeiten einzuplanen, bei denen wir im Grunde nur dasitzen und auf die Ausstellung von Zertifikaten warten. Ich füge meine eigene Antwort hinzu, da diese Frage ziemlich viel Verkehr hatte und sich herausstellte, dass Ausfallzeiten mit etwas Planung und Tests nicht notwendig sind.
So habe ich es gemacht:
- Stellen Sie temporäre Let’s Encrypt-Zertifikate für example.com aus.
- Importieren Sie die Zertifikate als selbstverwaltete Zertifikate.
- Richten Sie den Load Balancer für die Verwendung der selbstverwalteten Zertifikate ein.
- Aktualisieren Sie DNS-Einträge, damit diese auf den Load Balancer verweisen.
- Erstellen Sie von Google verwaltete Zertifikate und weisen Sie diese zu alszweiteZertifikat, neben dem selbstverwalteten Zertifikat.
- Warten Sie, bis das von Google verwaltete Zertifikat verfügbar ist
ACTIVE
. Dies kann lange dauern. Ohne das selbst verwaltete Zertifikat würde es zu Ausfallzeiten kommen. - Warten Sie 30 Minuten, bis das Zertifikat an alle Google Front Ends (GFEs) verteilt ist.
- Dem Load Balancer sind jetzt zwei Zertifikate zugewiesen. Aktualisieren Sie ihn, um nur das von Google verwaltete Zertifikat zu verwenden. Fertig!
Einzelheiten
Um das Problem zusammenzufassen: Die von Google verwalteten Zertifikate erfordern einen DNS-Eintrag, der auf einen Load Balancer verweist, dem das Zertifikat bereits zugewiesen ist, sonst werden sie nicht ausgestellt. Dies stellt ein Problem dar, da die Ausstellung des Zertifikats bis zu einer Stunde dauern kann und wir während dieser Zeit keine SSL-Fehler wünschen.
Die Problemumgehung, die ich gefunden habe, war die Verwendungselbstverwaltete Zertifikatewährend der Migration und Umstellung auf die von Google verwalteten Zertifikate, sobald unsere Domäne auf den GCP-Load Balancer verwies und die Zertifikate bereits ausgestellt worden waren.
ich benutzteLass uns verschlüsselnZertifikate, aber andere funktionieren auch. Ein Vorteil davon war, dass wir bereits Let's Encrypt-Zertifikate verwendeten, sodass ich mir keine Sorgen machen mussteZertifikatkompatibilität.
Hier ist eine vereinfachte Version meines Vorgehens. Der Zielproxy des Load Balancers wird aufgerufen my-target-proxy
, die Zertifikate heißen lb-certificate-letsencrypt
und lb-certificate-managed
. Die Domänennamen sind example.com
und subdomain.example.com
.
Voraussetzungen:
Generieren Sie ein neues, von Let’s Encrypt signiertes Zertifikat zur Verwendung als selbstverwaltetes Zertifikat:
openssl genrsa -out letsencrypt.pem 2048
Erstellen Sie eine OpenSSL-Konfigurationsdatei:
openssl.conf
[req]
default_bits = 2048
req_extensions = extension_requirements
distinguished_name = dn_requirements
[extension_requirements]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @sans_list
[dn_requirements]
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name (full name)
localityName = Locality Name (eg, city)
0.organizationName = Organization Name (eg, company)
organizationalUnitName = Organizational Unit Name (eg, section)
commonName = Common Name (e.g. server FQDN or YOUR name)
emailAddress = Email Address
[sans_list]
DNS.1 = example.com
DNS.2 = subdomain.example.com
Generieren Sie einZertifikatsignieranforderung:
openssl req -new -key letsencrypt.pem -out letsencrypt.csr -config openssl.conf
Holen Sie sich ein signiertes Zertifikat von Let’s Encrypt:
certbot certonly --csr letsencrypt.csr --manual --preferred-challenges dns
Aktualisieren Sie die von certbot angegebenen DNS-Einträge, um den Besitz zu bestätigen. Andere Herausforderungen könnten auch funktionieren, aber DNS schien am einfachsten.
Notieren Sie sich, welche Datei die vollständige Zertifikatskette darstellt, und ersetzen Sie diese 0003_chain.pem
bei Bedarf im Beispiel:
Die vollständige Zertifikatskette wird gespeichert unter: ...
Laden Sie das selbstverwaltete Zertifikat in GCP hoch und erstellen Sie es:
gcloud compute ssl-certificates create lb-certificate-letsencrypt \
--certificate=0003_chain.pem \
--private-key=letsencrypt.pem \
--global
Erstellen Sie den Load Balancer, zu dem Sie migrieren, oder konfigurieren Sie ihn für die Verwendung des selbstverwalteten Zertifikats:
gcloud beta compute target-https-proxies create my-target-proxy \
--ssl-certificates=lb-certificate-letsencrypt [url-map and other options]
# Or
gcloud beta compute target-https-proxies update my-target-proxy \
--ssl-certificates=lb-certificate-letsencrypt
Aktualisieren Sie DNS-Einträge, damit diese auf die IP Ihres Load Balancers verweisen. Dieser sollte nun in der Lage sein, TLS für example.com und subdomain.example.com zu beenden. Sie können diesen Schritt testen, indem Sie einen Eintrag für example.com in Ihre Hosts-Datei einfügen, der auf die IP des Load Balancers verweist. Die Antwort von John Hanley enthält hierzu viele gute Ratschläge.
Erstellen Sie das verwaltete Zertifikat:
gcloud compute ssl-certificates create lb-certificate-managed \
--domains=example.com,subdomain.example.com \
--global
Platzhalter werden von von Google verwalteten Zertifikaten nicht unterstützt. Stellen Sie daher sicher, dass Sie alle verwendeten Domänen auflisten.
Weisen Sie es dem Zielproxy zuzusammenmit dem selbstverwalteten Zertifikat. Zertifikate werden erst bereitgestellt, wenn sie einem Proxy zugewiesen werden:
gcloud beta compute target-https-proxies update my-target-proxy \
--ssl-certificates=lb-certificate-letsencrypt,lb-certificate-managed
Überprüfen Sie den Status:
gcloud compute ssl-certificates describe lb-certificate-managed
Warten Sie, bis status
sich von PROVISIONING
auf ändert ACTIVE
-jeder andere Statusist ein Fehler, der untersucht werden sollte. „Die Bereitstellung eines von Google verwalteten Zertifikats kann bis zu 60 Minuten dauern.“laut den Dokumenten(Let’s Encrypt macht dasselbe in Sekundenschnelle …).
Es kann weitere 30 Minuten dauern, bis es für den Einsatz durch einen Lastenausgleich verfügbar ist.
Daher,30 Minuten wartennachdem der Status auf geändert wurde ACTIVE
.
Aktualisieren Sie den Zielproxy, sodass nur das von Google verwaltete Zertifikat verwendet wird:
gcloud beta compute target-https-proxies update my-target-proxy \
--ssl-certificates=lb-certificate-managed
Es kann eine Weile dauern, bis die neue Einstellung übernommen wird. Überprüfen Sie den Aussteller für den Endpunkt im Browser oder mithilfe von OpenSSL:
openssl s_client -connect example.com:443 -showcerts \
-CAfile /etc/ssl/certs/ca-certificates.crt <<< Q
Herausgeber sollte nun „Google Trust Services LLC“ statt „Let’s Encrypt“ sein.
Das selbstverwaltete Let’s Encrypt-Zertifikat kann jetzt entfernt oder bis zu seinem Ablauf aufbewahrt werden, falls es Probleme mit dem verwalteten Zertifikat gibt.
Um das ungenutzte, selbstverwaltete Let’s Encrypt-Zertifikat zu bereinigen, führen Sie Folgendes aus:
gcloud compute ssl-certificates delete lb-certificate-letsencrypt
Antwort2
Sie werden Ausfallzeiten haben.
Sie können diese Tipps befolgen, um Ausfallzeiten zu minimieren. Bei richtiger Planung sind die Ausfallzeiten sehr kurz und in manchen Fällen sind sie durch automatische Wiederholungsversuche für Clients unsichtbar.
Ich kenne jedoch das Design Ihrer Site, die Verwendung von Cookies, die Authentifizierung, das Sitzungsmanagement usw. nicht. Es kann zu Störungen kommen, die unvermeidbar sind. Wenn möglich, senden Sie Ihren Kunden eine E-Mail, um sie vor der Site-Wartung zu informieren.
Dies ist ein guter Zeitpunkt, um Ihre Protokolle zu überprüfen. Suchen Sie nach möglichen Problemen beim Zugriff auf IP-Adressen. Diese Art von Problemen tritt auf, nachdem die Migration abgeschlossen ist und Sie das alte System heruntergefahren haben.
Denken Sie daran, dass DNS-Ressourceneinträge global zwischengespeichert werden. Die TTL des Ressourceneintrags gibt einen Hinweis darauf, wie lange. DNS-Resolver können Ihre TTL nach eigenem Ermessen interpretieren.
Notieren Sie sich die TTL der Ressourceneinträge, die Sie ändern möchten. Ändern Sie nun die TTL auf einen kurzen Wert, z. B. 1 Minute.
Warten Sie, bis mindestens die alte TTL abgelaufen ist, bevor Sie die endgültigen Änderungen vornehmen.
Richten Sie Ihre Dienste und den Lastenausgleich ein, bevor Sie DNS-Änderungen vornehmen. Stellen Sie sicher, dass die Dienste nur mit der IP-Adresse ordnungsgemäß funktionieren. Wenn Sie IP auf Domäne oder HTTP auf HTTPS umleiten, deaktivieren Sie diese Funktionen vorübergehend und aktivieren Sie sie später.
Verwenden Sie certbot im manuellen Modus und erstellen Sie ein Zertifikat, das Sie in den Load Balancer laden können. Dadurch entfällt der Schritt, bei dem der Load Balancer das SSL-Zertifikat erstellt und auf die Überprüfung wartet. Sie können später zu Google Managed SSL wechseln.
Konfigurieren Sie sowohl das HTTP- als auch das HTTPS-Frontend des Google Cloud Load Balancer. Konfigurieren Sie das Let’s Encrypt SSL-Zertifikat im Frontend.
Planen Sie, die alte Site nach der Migration etwa 30 Tage lang laufen zu lassen. Normalerweise sehe ich nach der Migration mehrere Wochen lang Verkehr auf der alten Site.
Wählen Sie die Tageszeit oder den Wochentag mit dem geringsten Datenverkehr. Wechseln Sie dann die DNS-Ressourceneinträge. Denken Sie daran, dass der alte TTL-Wert abgelaufen sein sollte, damit der neue TTL für die Zwischenspeicherung verwendet wird.
Nachdem Sie einige Tage später überprüft haben, dass alles funktioniert, setzen Sie die TTL-Werte auf einen normalen Wert wie604800Dies entspricht der Anzahl der Sekunden in einer Woche oder 86400 (einem Tag). Aktivieren Sie die Site-Umleitung (IP -> Domäne, HTTP -> HTTPS) erneut, falls verwendet.
Antwort3
Beachten Sie zusätzlich zu den vorherigen Vorschlägen, dass von Google verwaltete SSL-Zertifikate für regionale externe HTTP(S)-Load Balancer und interne HTTP(S)-Load Balancer nicht unterstützt werden. Für diese Load Balancer müssen Sie selbst verwaltete SSL-Zertifikate verwenden. Ich habe nicht gesehen, welche Art von Load Balancer Sie verwenden, aber bevor Sie versuchen, diese Migration einzurichten, müssen Sie dies berücksichtigen. Außerdem in diesemFührungSie konnten sehen, wie man von Google verwaltete SSL-Zertifikate erstellt und verwendet und welche Überlegungen für die korrekte Funktionsweise angestellt werden müssen.1.
Ich würde Ihnen empfehlen, ein Wartungsfenster für diese Änderungen festzulegen, da es bis zu 30 Minuten dauern kann, bis das Zertifikat für alle Google Front Ends (GFEs) verfügbar ist.
Darüber hinausHier Sie erhalten die offizielle Anleitung mit der Schritt-für-Schritt-Anleitung zum Erreichen dieses Verhaltens.
1 https://cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs
2 https://cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs#migrating-ssl