Der Zertifikatmanager verwendet einen flexiblen Zuordnungsmechanismus, lässt sich genau steuern, welche Zertifikate wie sie für jeden Domainnamen in Ihrer Umgebung bereitgestellt werden. Der Mechanismus umfasst die folgenden Entitäten:
- Zertifikate
- Zertifikatszuordnungen
- Zertifikatszuordnungseinträge
- Domainautorisierungen
Das folgende Diagramm veranschaulicht die Beziehungen zwischen diesen Entitäten Einen typischen Zielproxy, der in einer Weiterleitungsregel für den Load-Balancer angegeben ist:
Zertifikatmanager unterstützt Ziel-HTTPS-Proxys und Ziel-SSL Proxys. Weitere Informationen zu den Unterschieden zwischen diesen Proxy-Typen finden Sie Siehe Zielproxys verwenden.
Informationen zu den Zertifikatstypen, die Zertifikat-Manager unterstützt, siehe Bereitstellungsübersicht.
Zertifikate
Standardmäßig stellt ein Zertifikat eine einzelne X.509-Transportschichtsicherheit dar. TLS-/SSL-Zertifikat, das für bestimmte Domainnamen oder Domains ausgestellt wird Platzhalter verwenden.
Certificate Manager unterstützt die folgenden Zertifikatstypen:
- Von Google verwaltete Zertifikate sind Zertifikate, die Google Cloud für Sie übernimmt und verwaltet.
- Selbstverwaltete Zertifikate sind Zertifikate, die Sie erwerben, bereitstellen und sich selbst zu erneuern.
Wenn Sie ein Zertifikat mit einer öffentlich vertrauenswürdigen Zertifizierungsstelle ausstellen, veröffentlicht die Zertifizierungsstelle Informationen zur zugehörigen Domain in Certificate Transparency-Protokollen, die öffentlich zugänglich sind. Dies ist Teil des standardmäßigen Zertifikatsausstellungsverfahrens, das von allen öffentlich vertrauenswürdigen Zertifizierungsstellen verwendet wird. Es gilt sowohl für von Google verwaltete als auch für selbstverwaltete Zertifikate. Wenn Sie jedoch Certificate Authority Service, um Ihr von Google verwaltetes Zertifikat Im Zertifikatmanager werden keine Informationen Certificate Transparency-Protokolle.
Weitere Informationen finden Sie unter Certificate Transparency:
Informationen zum Bereitstellen eines Zertifikats mit dem Zertifikatsmanager finden Sie in der Bereitstellungsübersicht.
Von Google verwaltete Zertifikate
Von Google verwaltete TLS (SSL)-Zertifikate für Websites und Anwendungen verwalten kann eine komplexe und zeitaufwendige Aufgabe sein, die oft eine manuelle Konfiguration erfordert und regelmäßige Wartung. Der Zertifikatmanager ist ein Dienst, können Sie diesen Prozess optimieren, indem Sie eine zentrale Plattform bereitstellen. Sie können die Verantwortung für die Ausstellung und Verlängerung von Zertifikaten an Certificate Manager, damit Sie mehr Zeit für andere Aufgaben haben für kritische Aufgaben.
Sie können die relevante Domaininhaberschaft bestätigen, indem Sie auf Load-Balancer-Basis oder DNS-basierte Autorisierung. Certificate Manager unterstützt von Google verwaltete RSA-Zertifikate.
Standardmäßig stellt die Google-Zertifizierungsstelle von Google verwaltete Zertifikate aus. Wenn eine neue Das von Google verwaltete Zertifikat wird ausgestellt oder erneuert. Es wird ein neu generiertes privaten Schlüssel enthält. Wenn Sie für eine bestimmte Domain kein Zertifikat von der Google-Zertifizierungsstelle erhalten können, greift der Zertifikatsmanager auf die Let's Encrypt-Zertifizierungsstelle zurück. Für Es kann z. B. sein, dass die Google-Zertifizierungsstelle die Ausstellung eines Zertifikats für die Domain weigert oder Ihr CA-Autorisierungseintrag untersagt der Google-Zertifizierungsstelle ausdrücklich Folgendes: Zertifikate für diese Domain.
Die Authentifizierung nur auf Clientseite wird nicht unterstützt.
Anleitungen zum Einschränken der Zertifizierungsstellen, die Zertifikate für finden Sie unter Zertifizierungsstellen angeben, die Ihr von Google verwaltetes Zertifikat ausstellen können
Regionale von Google verwaltete Zertifikate unterstützen nur DNS-basierte und Zertifikate von der Google-Zertifizierungsstelle erhalten.
Von Google verwaltete Zertifikate, die von Certificate Authority Service ausgestellt wurden
Wenn Sie Ihre eigene Vertrauenskette verwenden möchten, anstatt sich bei der Ausstellung Ihrer Zertifikate auf von Google genehmigte öffentliche Zertifizierungsstellen zu verlassen, können Sie den Certificate Manager so konfigurieren, dass stattdessen ein CA-Pool aus dem Certificate Authority Service als Zertifikataussteller verwendet wird. Weitere Informationen zu CA-Pools finden Sie unter CA-Pools erstellen
Selbstverwaltete Zertifikate
Wenn es aufgrund Ihrer geschäftlichen Anforderungen nicht möglich ist, von Google verwaltete können Sie Zertifikate hochladen, die von externen Zertifizierungsstellen ausgestellt wurden, die zugehörigen Schlüssel an. Sie sind für die manuelle Ausstellung und Verlängerung selbstverwaltete Zertifikate.
Mit dem Zertifikatmanager können Sie auch regionale selbstverwaltete Zertifikate auf Secure Web Proxy-Proxys und regional Lastenausgleichsmodule.
Zertifikatszuordnungen
Eine Zertifikatszuordnung verweist auf einen oder mehrere Zertifikatszuordnungseinträge, die eine bestimmte Zertifikate für bestimmte Hostnamen. Zertifikatszuordnungseinträge definieren auch die Auswahllogik, der der Load Balancer beim Herstellen von Clientverbindungen folgt. Sie können eine Zertifikatszuordnung mit mehreren Zielproxys verknüpfen zur Wiederverwendung über mehrere Load-Balancer hinweg.
Wenn ein Client einen in einer Zertifikatszuordnung angegebenen Hostnamen anfordert, gibt der Load Balancer die diesem Hostnamen zugeordneten Zertifikate zurück. Andernfalls wird die Last das primäre Zertifikat bereitstellt. Weitere Informationen Siehe Logik für Zertifikatsauswahl.
Zertifikatszuordnungseinträge
Ein Eintrag für die Zertifikatszuordnung ist eine Liste von Zertifikaten, die für eine bestimmte Domain-Namen eingeben. Sie können verschiedene Gruppen von Zertifikaten für unterschiedliche Domainnamen, wie Domains oder Sub-Domains. Sie können beispielsweise ein ECDSA- und ein RSA-Zertifikat hochladen und ihnen denselben Domainnamen zuordnen. Wenn ein Client eine Verbindung zu diesem Domainnamen herstellt, verhandelt der Load Balancer während des Handshakes den Zertifikatstyp, der dem Client zur Verfügung gestellt werden soll.
Domainautorisierungen
Mit dem Zertifikatmanager können Sie die Inhaberschaft von Domains nachweisen, für die Sie von Google verwaltete Zertifikate ausstellen möchten, wie im Folgenden beschrieben .
| Load-Balancer-Autorisierung | DNS-Autorisierung | |
|---|---|---|
| Komplexität der Einrichtung | Erfordert keine zusätzlichen Konfigurationsschritte oder Änderungen an der DNS-Konfiguration. | Erfordert das Erstellen einer DNS-Autorisierung und das Hinzufügen der zugehörigen CNAME-Eintrag zu Ihrer DNS-Konfiguration hinzufügen. |
| Netzwerksicherheit | Der Load-Balancer muss über das Internet vollständig über den Port zugänglich sein 443, einschließlich der DNS-Konfiguration für alle Domains, Zertifikat. Funktioniert nicht mit anderen Konfigurationen. | Funktioniert mit hochkomplexen Konfigurationen, z. B. mit anderen Ports als und CDN-Ebene vor dem Zielproxy. |
| Bereitstellungsgeschwindigkeit | Sie können Zertifikate erst bereitstellen, nachdem der Load Balancer vollständig eingerichtet und für den Netzwerkverkehr verfügbar ist. | Sie können Zertifikate im Voraus bereitstellen, bevor der Zielproxy bereitgestellt wird kann Netzwerkverkehr bereitgestellt werden. |
So bestätigt der Zertifikatmanager die Domaininhaberschaft mithilfe der beiden Methoden, siehe Domainautorisierungen für von Google verwaltete Zertifikate
Konfigurationen der Zertifikatsausstellung
Eine Konfiguration für die Zertifikatsausstellung ist eine Ressource, die den Zertifikatmanager zulässt So verwenden Sie einen Zertifizierungsstellenpool aus Ihrer eigenen Certificate Authority Service-Instanz statt der Google-Zertifizierungsstelle oder der Let's Encrypt-Zertifizierungsstelle von Google verwaltete Zertifikate auszustellen. Damit können Sie um eine Reihe von Parametern festzulegen, die die Ausstellung und den Ablauf von Zertifikaten sowie den Schlüsselalgorithmus für Zertifikate aus, die auf diese Weise ausgestellt werden.
Konfigurationen von Vertrauensstellungen
Eine Vertrauenskonfiguration ist eine Ressource, die Ihre Konfiguration der Public-Key-Infrastruktur (PKI) im Zertifikatmanager zur Verwendung in Szenarien mit gegenseitiger TLS-Authentifizierung darstellt. Sie enthält einen einzelnen Trust Store, der wiederum einen Trust-Anchor und optional ein oder mehrere Zwischenzertifikate enthält.
Weitere Informationen zur gegenseitigen TLS-Authentifizierung finden Sie unter Gegenseitige TLS-Authentifizierung in der Cloud Load Balancing-Dokumentation.
Eine Konfigurationsressource der Vertrauensstellung enthält den Trust Store, den Trust Anchor und das Zwischenzertifikat Entitäten.
Trust Stores
Ein Trust Store steht für die Konfiguration von Trust-Secrets im Zertifikatmanager zur Verwendung in Szenarien mit gegenseitiger TLS-Authentifizierung. Sie enthält einen einzelnen Trust-Anchor und optional ein oder mehrere Zwischenzertifikate.
Trust-Anchors
Ein Trust-Anchor steht für ein einzelnes Root-Zertifikat zur Verwendung in gegenseitigem TLS. Authentifizierungsszenarien. Sie ist in einem Trust Store gekapselt.
Zwischenzertifikate
Ein Zwischenzertifikat ist ein einzelnes Zwischenzertifikat, das von einem Root-Zertifikat signiert wurde, oder ein Zwischenzertifikat, auf das im gekapselnden Trust Store für die Verwendung in Szenarien mit gegenseitiger TLS-Authentifizierung verwiesen wird.
Ein oder mehrere Zwischenzertifikate können in einem Trust Store gekapselt werden. abhängig von Ihrer PKI-Konfiguration. Alle Zwischenzertifikate angegeben in einer Konfiguration der Vertrauensstellung in die Vertrauensbewertung für alle Verbindungsanfrage zusätzlich zur Liste der Zwischenzertifikate die in der Anfrage selbst angegeben sind.
Zertifikate, für die eine Zulassungsliste erforderlich ist
Wenn Sie ein selbst signiertes Zertifikat benötigen,
abgelaufen sind oder anderweitig ungültig sind oder wenn Sie keinen Zugriff auf das Stammverzeichnis
Zwischenzertifikaten können Sie dieses Zertifikat der Konfiguration der Vertrauensstellung hinzufügen.
Das Feld allowlistedCertificates. Sie benötigen keinen Trust Store, um eine
auf eine Zulassungsliste setzen.
Wenn Sie der Zulassungsliste ein Zertifikat hinzufügen, ist es immer als gültig angesehen, solange das Zertifikat geparst werden kann; Nachweis des privaten Schlüssels der Besitz und die Einschränkungen für das SAN-Feld des Zertifikats erfüllt sind.
Logik für die Zertifikatsauswahl
Auf übergeordneter Ebene wählt der Load-Balancer ein Zertifikat wie folgt aus:
- Ein Client initiiert einen Handshake. Dabei stellt er dem Load Balancer eine Liste der kryptografischen Algorithmen zur Verfügung, die er zum Abschluss des Handshakes verwenden kann, und optional einen Hostnamen.
Der Load-Balancer wählt ein Zertifikat aus, um den sicheren Handshake abzuschließen. auf dem vom Client bereitgestellten Hostnamen und der konfigurierten Zertifikatszuordnung Einträge. Die Faktoren, die bestimmen, welches Zertifikat der Load-Balancer verwendet Auswahlen sind wie folgt:
Genaue Übereinstimmung mit dem Hostnamen: Wenn der Client einen Hostnamen bereitstellt, der genau mit einem Eintrag in der bereitgestellten Zertifikatszuordnung übereinstimmt, wählt der Load-Balancer das entsprechende Zertifikat aus.
Übereinstimmung mit Platzhalter-Hostnamen: Wenn der Hostname des Clients mit keinem Eintrag übereinstimmt, aber mit einem Platzhalter-Hostnamen in einem Zertifikatzuordnungseintrag übereinstimmt, wählt der Load-Balancer das entsprechende Zertifikat aus diesem Eintrag aus. Beispielsweise deckt ein Platzhaltereintrag, der als
*.myorg.example.comkonfiguriert ist, Subdomains der ersten Ebene unter der Domainmyorg.example.comab.Keine Hostname-Übereinstimmung und ein vorkonfigurierter Eintrag für die primäre Zertifikatszuordnung: Der Load-Balancer wählt einen vorkonfigurierten Eintrag für die primäre Zertifikatszuordnung aus, wenn keine Hostnamenübereinstimmung oder kein übereinstimmender Eintrag für eine bereitgestellte Zertifikatszuordnung vorhanden ist.
Handshake-Fehler: Der Handshake schlägt fehl, wenn der Load Balancer aus den folgenden Gründen kein übereinstimmendes Zertifikat findet:
- Der Client stellt einen Hostnamen bereit, der mit keinem exakten Hostnamen oder Platzhalter-Hostnamen übereinstimmt, der in allen bereitgestellten Zertifikatszuordnungseinträgen angegeben ist, oder aber keinen Hostnamen angibt.
- Es wurde kein übereinstimmender Eintrag für die primäre Zertifikatszuordnung gefunden oder Sie haben keinen Eintrag für die primäre Zertifikatszuordnung konfiguriert.
Zertifikatspriorität
Der Load-Balancer wählt ein Zertifikat innerhalb eines Zertifikatszuordnungseintrags basierend auf Folgendes:
- Zertifikattyp. Wenn der Verbindungsclient die sicherere ECDSA-Funktion unterstützt Zertifikate, priorisiert der Load-Balancer sie gegenüber RSA-Zertifikaten. Wenn die Client gibt keine Unterstützung für ECDSA-Zertifikate an, der Load-Balancer ein RSA-Zertifikat aus.
- Zertifikatgröße. Der Load-Balancer priorisiert Zertifikate von der kleinsten zum größten aus.
Platzhalter-Domainnamen
Für Domainnamen mit Platzhaltern gelten die folgenden Regeln:
- Nur von Google verwaltete Zertifikate mit DNS-Autorisierung und von Google verwaltete Zertifikate mit CA-Dienst unterstützen Platzhalter-Domainnamen. Von Google verwaltete Zertifikate mit Load-Balancer-Autorisierung unterstützen keine Domainnamen mit Platzhaltern.
- Eine genaue Übereinstimmung hat Vorrang vor einem Platzhalter, wenn beide Werte im
zu erstellen. Wenn Sie beispielsweise Zertifikatzuordnungseinträge für
www.myorg.example.comund*.myorg.example.comkonfiguriert haben, wird bei einer Verbindungsanfrage anwww.myorg.example.comimmer der Eintrag fürwww.myorg.example.comausgewählt, auch wenn ein Eintrag für*.myorg.example.comvorhanden ist. - Platzhalter-Domainnamen stimmen nur bis zu einer Subdomain-Ebene überein. Bei einer Verbindungsanfrage für
host1.myorg.example.comwird beispielsweise ein Zertifikatzuordnungseintrag für*.myorg.example.comausgewählt, aber keiner fürhost1.hosts.myorg.example.com.
Public CA
Um die Funktion für öffentliche Zertifizierungsstellen des Zertifikatmanagers zu verwenden, müssen Sie mit den folgenden Konzepten:
ACME-Client. Ein ACME-Client (Automatic Certificate Management Environment) ist ein Zertifikat Management-Client, der das ACME-Protokoll verwendet. Ihr ACME-Client muss die externe Kontobindung (EAB) unterstützen, damit Sie mit einer öffentlichen Zertifizierungsstelle arbeiten können.
Externe Kontobindung (External Account Binding, EAB) Sie müssen jedes ACME-Konto binden, das Sie mit dem Zertifikatmanager verwenden öffentliche Zertifizierungsstelle mit externer Kontobindung an das Google Cloud-Zielprojekt. Dazu müssen Sie jedes ACME-Konto mit einem Secret, das mit dem entsprechenden Google Cloud-Projekt verknüpft ist. Weitere Informationen finden Sie unter Externes Konto. binding.
Herausforderungen der Public CA
Wenn Sie eine öffentliche Zertifizierungsstelle verwenden, um ein Zertifikat anzufordern, werden Sie von Certificate Manager aufgefordert, nachzuweisen, dass Sie die Kontrolle über die in diesem Zertifikat aufgeführten Domains haben. Sie können die Domainkontrolle nachweisen, indem Sie Herausforderungen lösen. Die öffentliche Zertifizierungsstelle autorisiert die Domainnamen, nachdem Sie nachgewiesen haben, dass Sie die Kontrolle über die Zieldomains haben.
Nachdem Sie die erforderlichen Autorisierungen erhalten haben, können Sie Zertifikate anfordern, die nur für einen bestimmten Zeitraum gültig sind. Nach Ablauf dieser Frist müssen Sie den Domainnamen noch einmal validieren indem Sie eine der drei Aufgabentypen lösen, um weiterhin Zertifikate anfordern zu können.
Typen der Identitätsbestätigung
Public CA unterstützen die folgenden Arten von Identitätsbestätigungen:
HTTP-Abfrage. Dabei muss eine Datei in einem bekannten Format erstellt werden, Speicherort auf einem HTTP-Server (Port 80), den Public CA abrufen kann zu überprüfen. Weitere Informationen finden Sie unter HTTP-Abfrage.
TLS-Application Layer Protocol Negotiation (ALPN): Erfordert eine Server, um während einer TLS-Verhandlung auf Port 443 ein bestimmtes Zertifikat bereitzustellen um die Kontrolle über eine Domain nachzuweisen. Weitere Informationen finden Sie unter ACME TLS-ALPN Challenge Extension
DNS-Abfrage: Erfordert das Hinzufügen eines bestimmten DNS-Eintrags unter einem definierten Standort, um die Kontrolle über eine Domain nachzuweisen. Weitere Informationen finden Sie unter DNS-Abfrage.
Wenn Sie die HTTP- oder TLS-ALPN-Abfrage zur Validierung einer Domainname kann der Client nur die validierte Domain anfordern. in ein Zertifikat aufzunehmen. Wenn Sie die DNS-Abfrage verwenden, kann der Client auch Subdomains dieses Domainnamens anfordern, die dann in eine Zertifikat.
Wenn Sie beispielsweise *.myorg.example.com mit der DNS-Herausforderung validieren, werden subdomain1.myorg.example.com und subdomain2.myorg.example.com automatisch vom Platzhalterzertifikat abgedeckt. Wenn Sie jedoch myorg.example.com mit einem HTTP- oder
Die TLS-ALPN-Abfrage kann vom Client nur angefordert werden, um myorg.example.com aufzunehmen
und Sie können *.myorg.example.com nicht mit anderen Identitätsbestätigungen validieren.
Logik der Herausforderungslösung
Die Logik der Identitätsbestätigung für öffentliche Zertifizierungsstellen sieht so aus:
- Die öffentliche Zertifizierungsstelle stellt ein zufälliges Token bereit.
- Der Client stellt das Token an einem klar definierten Standort zur Verfügung. Die ist von der jeweiligen Herausforderung abhängig.
- Der Client gibt der Public CA an, dass er den Herausforderung.
- Public CA prüft, ob das Token am erwarteten Ort vorhanden ist Standort mit dem erwarteten Wert übereinstimmt.
Der Domainname wird autorisiert, nachdem dieser Vorgang abgeschlossen ist. Der Kunde kann Fordern Sie ein Zertifikat mit diesem Domainnamen an. Sie müssen nur eine lösen für jede Domain-Name.