Der Zertifikatmanager nutzt einen flexiblen Zuordnungsmechanismus, mit dem Sie genau steuern können, welche Zertifikate Sie zuweisen können und wie sie für jeden Domainnamen in Ihrer Umgebung bereitgestellt werden. Der Mechanismus umfasst die folgenden Entitäten:
- Zertifikate
- Zertifikatszuordnungen
- Einträge in Zertifikatszuordnungen
- Domainautorisierungen
Das folgende Diagramm zeigt die Beziehungen zwischen diesen Entitäten für einen typischen Zielproxy, der in einer Load-Balancer-Weiterleitungsregel angegeben ist:
Der Zertifikatmanager unterstützt Ziel-HTTPS-Proxys und Ziel-SSL-Proxys. Weitere Informationen zu den Unterschieden zwischen diesen Proxytypen finden Sie unter Zielproxys verwenden.
Mithilfe des Zertifikatmanagers können Sie Ihre Zertifikate folgendermaßen anhängen:
- Wenn Sie Zertifikate für globale externe Application Load Balancer bereitstellen, verwenden Sie Zertifikatszuordnungen, die an Zielproxys und Zertifikatszuordnungseinträge angehängt sind. Weitere Informationen finden Sie unter Globales selbstverwaltetes Zertifikat bereitstellen.
- Wenn Sie Zertifikate für regionale externe Application Load Balancer, regionale interne Application Load Balancer oder Secure Web Proxy-Gateways bereitstellen, hängen Sie Zertifikate direkt an Zielproxys oder Secure Web Proxy-Gateways an. Weitere Informationen finden Sie unter Regionales selbstverwaltetes Zertifikat bereitstellen.
- Wenn Sie Zertifikate für regionsübergreifende interne Application Load Balancer bereitstellen, hängen Sie Zertifikate mit dem Bereich
ALL_REGIONSdirekt an Zielproxys an. Regionsübergreifende interne Application Load Balancer unterstützen keine von Google verwalteten Zertifikate mit Load-Balancer-Autorisierung. Sie unterstützen jedoch die DNS-Autorisierung und die Autorisierung von Certificate Authority Service.
Zertifikate
Standardmäßig stellt ein Zertifikat ein einzelnes SSL-Zertifikat (X.509 Transport Layer Security) (SSL) dar, das für bestimmte Domainnamen oder Domainplatzhalter ausgestellt wird.
Der Zertifikatmanager unterstützt die folgenden Arten von Zertifikaten:
- Von Google verwaltete Zertifikate sind Zertifikate, die Google Cloud für Sie abruft und verwaltet.
- Selbstverwaltete Zertifikate sind Zertifikate, die Sie selbst erwerben, bereitstellen und verlängern.
Wenn Sie ein Zertifikat über eine öffentlich vertrauenswürdige Zertifizierungsstelle ausstellen, veröffentlicht die Zertifizierungsstelle Informationen zur verknüpften Domain in Certificate Transparency-Logs, die öffentlich zugänglich sind. Dieser Schritt ist Teil des Standardverfahrens zur Zertifikatsausstellung, das von allen öffentlich vertrauenswürdigen Zertifizierungsstellen angewendet wird, und gilt sowohl für von Google verwaltete als auch für selbstverwaltete Zertifikate. Wenn Sie Ihr von Google verwaltetes Zertifikat jedoch über den Certificate Authority Service ausstellen, veröffentlicht der Zertifikatmanager keine Informationen in Certificate Transparency-Logs.
Weitere Informationen finden Sie unter Zertifikatstransparenz.
Informationen zum Bereitstellen eines Zertifikats mit dem Zertifikatmanager finden Sie unter Bereitstellungsübersicht.
Von Google verwaltete Zertifikate
Die Verwaltung von von Google verwalteten TLS-Zertifikaten (SSL) für Ihre Websites und Anwendungen kann eine komplexe und zeitaufwendige Aufgabe sein, die oft eine manuelle Konfiguration und regelmäßige Wartung erfordert. Der Zertifikatmanager ist ein Dienst, mit dem Sie diesen Prozess durch Bereitstellung einer zentralen Plattform optimieren können. Sie können die Verantwortung für das Ausstellen und Verlängern von Zertifikaten an den Zertifikatmanager delegieren, sodass Sie Zeit haben, sich auf andere wichtige Aufgaben zu konzentrieren.
Sie können die Domaininhaberschaft entweder mit einer Load-Balancer- oder einer DNS-basierten Autorisierung bestätigen. Der Zertifikatmanager unterstützt von Google verwaltete RSA-Zertifikate.
Standardmäßig stellt die Google-Zertifizierungsstelle von Google verwaltete Zertifikate aus. Wenn ein neues von Google verwaltetes Zertifikat ausgestellt oder verlängert wird, wird ein neu generierter privater Schlüssel verwendet. Wenn Sie von der Google-Zertifizierungsstelle kein Zertifikat für eine bestimmte Domain erhalten können, greift der Zertifikatmanager auf die "Let's Encrypt"-Zertifizierungsstelle zurück. Beispielsweise verweigert die Google-Zertifizierungsstelle möglicherweise die Ausstellung eines Zertifikats für die Domain oder Ihr CA-Autorisierungseintrag verhindert explizit, dass die Google-Zertifizierungsstelle Zertifikate für diese Domain ausstellt.
Die Authentifizierung nur auf Clientseite wird nicht unterstützt.
Eine Anleitung zum Einschränken der Zertifizierungsstellen, die Zertifikate für Ihre Domains ausstellen können, finden Sie unter Zertifizierungsstellen angeben, die Ihr von Google verwaltetes Zertifikat ausstellen können.
Regionale von Google verwaltete Zertifikate (Vorschau) unterstützen nur die DNS-basierte Autorisierung und erhalten Zertifikate von der Google-Zertifizierungsstelle.
Von Google verwaltete Zertifikate, die vom Certificate Authority Service ausgestellt wurden
Wenn Sie Ihre eigene Vertrauenskette verwenden möchten, um Ihre Zertifikate nicht auf von Google genehmigte öffentliche Zertifizierungsstellen auszustellen, können Sie den Zertifikatsmanager so konfigurieren, dass stattdessen ein CA-Pool des Certificate Authority Service als Zertifikatsaussteller verwendet wird. Weitere Informationen zu CA-Pools finden Sie unter CA-Pools erstellen.
Selbstverwaltete Zertifikate
Wenn Ihre geschäftlichen Anforderungen die Verwendung von von Google verwalteten Zertifikaten nicht zulassen, können Sie von externen Zertifizierungsstellen ausgestellte Zertifikate zusammen mit den zugehörigen Schlüsseln hochladen. Sie sind dafür verantwortlich, selbstverwaltete Zertifikate manuell auszustellen und zu verlängern.
Mit dem Zertifikatmanager können Sie auch regionale selbstverwaltete Zertifikate auf Secure Web Proxy-Proxys und regionalen Load-Balancern bereitstellen.
Zertifikatszuordnungen
Eine Zertifikatszuordnung verweist auf einen oder mehrere Zertifikatszuordnungseinträge, die bestimmte Zertifikate bestimmten Hostnamen zuweisen. 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, um sie in mehreren Load-Balancern wiederzuverwenden.
Wenn ein Client einen in einer Zertifikatszuordnung angegebenen Hostnamen anfordert, stellt der Load-Balancer die Zertifikate bereit, die diesem Hostnamen zugeordnet sind. Andernfalls stellt der Load-Balancer das primäre Zertifikat bereit. Weitere Informationen finden Sie unter Logik für die Zertifikatsauswahl.
Einträge in Zertifikatszuordnungen
Ein Zertifikatszuordnungseintrag ist eine Liste von Zertifikaten, die für einen bestimmten Domainnamen bereitgestellt werden. Sie können verschiedene Sätze von Zertifikaten für unterschiedliche Domainnamen wie Domains oder Subdomains definieren. Sie können beispielsweise ein ECDSA- und ein RSA-Zertifikat hochladen und sie demselben Domainnamen zuordnen. Wenn ein Client eine Verbindung zu diesem Domainnamen herstellt, handelt der Load-Balancer den Zertifikatstyp aus, der dem Client während des Handshakes bereitgestellt 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 in der folgenden Tabelle beschrieben.
| Load-Balancer-Autorisierung | DNS-Autorisierung | |
|---|---|---|
| Komplexität der Einrichtung | Erfordert keine zusätzlichen Konfigurationsschritte oder Änderungen an der DNS-Konfiguration. | Sie müssen dafür eine DNS-Autorisierung erstellen und der DNS-Konfiguration den entsprechenden CNAME-Eintrag hinzufügen. |
| Netzwerksicherheit | Der Load-Balancer muss über das Internet vollständig über Port 443 zugänglich sein, einschließlich der DNS-Konfiguration für alle vom Zertifikat bereitgestellten Domains. Funktioniert nicht mit anderen Konfigurationen. | Funktioniert mit Konfigurationen mit hoher Komplexität, z. B. mit anderen Ports als 443 und CDN-Ebenen vor dem Zielproxy. |
| Bereitstellungsgeschwindigkeit | Sie können Zertifikate erst bereitstellen, wenn der Load-Balancer vollständig eingerichtet ist und Netzwerkverkehr bereitstellt. | Sie können Zertifikate im Voraus bereitstellen, bevor der Zielproxy für die Bereitstellung von Netzwerkverkehr bereit ist. |
Informationen dazu, wie der Zertifikatmanager die Domaininhaberschaft mit den einzelnen Methoden überprüft, finden Sie unter Domainautorisierung für von Google verwaltete Zertifikate.
Konfigurationen für die Zertifikatsausstellung
Eine Konfiguration der Zertifikatsausstellung ist eine Ressource, mit der der Zertifikatmanager einen CA-Pool aus Ihrer eigenen Certificate Authority Service-Instanz verwenden kann, um von Google verwaltete Zertifikate anstelle der Google-Zertifizierungsstelle oder der "Let's Encrypt"-Zertifizierungsstelle auszustellen. Sie können damit eine Reihe von Parametern für die Ausstellung und den Ablauf von Zertifikaten festlegen und den Schlüsselalgorithmus für auf diese Weise ausgestellte Zertifikate auswählen.
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 Dokumentation zu Cloud Load Balancing.
Eine Konfigurationsressource der Vertrauensstellung kapselt Trust Store-, Trust-Anchor- und Zwischenzertifikatentitäten.
Trust Stores
Ein Trust Store stellt die Konfiguration des Vertrauens-Secrets im Zertifikatmanager zur Verwendung in Szenarien mit gegenseitiger TLS-Authentifizierung dar. Sie kapselt einen einzelnen Trust-Anchor und optional ein oder mehrere Zwischenzertifikate.
Trust-Anchors
Ein Trust-Anchor stellt ein einzelnes Root-Zertifikat zur Verwendung in Szenarien mit gegenseitiger TLS-Authentifizierung dar. 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 einschließenden Trust Store zur Verwendung in Szenarien der gegenseitigen TLS-Authentifizierung verwiesen wird.
Je nach PKI-Konfiguration können ein oder mehrere Zwischenzertifikate in einem Trust Store gekapselt werden. Alle Zwischenzertifikate, die in einer Konfiguration der Vertrauensstellung angegeben sind, werden für jede Verbindungsanfrage in die Bewertung der Vertrauensstellung einbezogen sowie die Liste der Zwischenzertifikate, die in der Anfrage selbst angegeben sind.
Zertifikate auf der Zulassungsliste
Ein Zertifikat auf der Zulassungsliste stellt jedes Zertifikat dar, das in der Konfiguration der Vertrauensstellung gekapselt werden kann, sodass sie immer als gültig angesehen werden. Ein Zertifikat auf der Zulassungsliste gilt immer als gültig, solange es geparst werden kann, ein Nachweis über den Besitz eines privaten Schlüssels vorliegt und Einschränkungen für das SAN-Feld des Zertifikats erfüllt sind. Abgelaufene Zertifikate gelten auch als gültig, wenn sie auf die Zulassungsliste gesetzt werden. Sie benötigen keinen Trust Store, wenn Sie Zertifikate auf der Zulassungsliste verwenden.
Logik zur Zertifikatsauswahl
Auf übergeordneter Ebene wählt der Load-Balancer ein Zertifikat so aus:
- Ein Client initiiert einen Handshake. In diesem Schritt stellt er dem Load-Balancer eine Liste von kryptografischen Algorithmen zur Verfügung, die für den Handshake verwendet werden können, und optional einen Hostnamen.
Der Load-Balancer wählt ein Zertifikat aus, um den sicheren Handshake anhand des vom Client angegebenen Hostnamens und der konfigurierten Zertifikatszuordnungseinträge abzuschließen. Die folgenden Faktoren bestimmen, welches Zertifikat der Load-Balancer auswählt:
Genaue Hostname-Übereinstimmung: Wenn der Client einen Hostnamen angibt, 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 keinen Einträgen übereinstimmt, aber mit einem Platzhalter-Hostnamen in einem Zertifikatszuordnungseintrag übereinstimmt, wählt der Load-Balancer das entsprechende Zertifikat aus diesem Eintrag aus. Ein Platzhaltereintrag, der als
*.myorg.example.comkonfiguriert ist, deckt beispielsweise Subdomains der ersten Ebene unter der Domainmyorg.example.comab.Keine Übereinstimmung mit dem Hostnamen und einem vorkonfigurierten Eintrag in der primären Zertifikatszuordnung: Der Load-Balancer wählt einen vorkonfigurierten Eintrag in der primären Zertifikatszuordnung aus, wenn kein Hostname oder ein übereinstimmender Eintrag für die bereitgestellte Zertifikatszuordnung vorliegt.
Handshakefehler: Der Handshake schlägt fehl, wenn der Load-Balancer aus folgenden Gründen kein passendes Zertifikat findet:
- Der Client stellt einen Hostnamen bereit, der mit keinem exakten Hostnamen oder Platzhalter-Hostnamen übereinstimmt, der in allen bereitgestellten Zertifikatzuordnungseinträgen angegeben ist, oder gibt keinen Hostnamen an.
- 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 anhand folgender Kriterien aus:
- Zertifikattyp: Wenn der verbindende Client die sichereren ECDSA-Zertifikate unterstützt, hat der Load-Balancer Vorrang vor RSA-Zertifikaten. Wenn der Client keine Unterstützung für ECDSA-Zertifikate angibt, stellt der Load-Balancer stattdessen ein RSA-Zertifikat bereit.
- Zertifikatgröße: Der Load-Balancer priorisiert Zertifikate in absteigender Reihenfolge.
Platzhalter-Domainnamen
Für Platzhalter-Domainnamen gelten die folgenden Regeln:
- Nur von Google verwaltete Zertifikate mit DNS-Autorisierung und von Google verwaltete Zertifikate mit CA Service unterstützen Platzhalter-Domainnamen. Von Google verwaltete Zertifikate mit Load-Balancer-Autorisierung unterstützen keine Platzhalter-Domainnamen.
- Eine genaue Übereinstimmung hat Vorrang vor einem Platzhalter, wenn beide im Eintrag definiert sind. Wenn Sie beispielsweise Einträge für die Zertifikatszuordnung für
www.myorg.example.comund*.myorg.example.comkonfiguriert haben, wird bei einer Verbindungsanfrage fürwww.myorg.example.comimmer der Eintrag fürwww.myorg.example.comausgewählt, auch wenn ein Eintrag für*.myorg.example.comebenfalls vorhanden ist. - Platzhalter-Domainnamen stimmen nur bis zu einer Subdomain-Ebene überein. Eine Verbindungsanfrage für
host1.myorg.example.comwählt beispielsweise einen Zertifikatzuordnungseintrag für*.myorg.example.comaus, aber keinen Eintrag fürhost1.hosts.myorg.example.com.
Public CA
Damit Sie die Funktion für öffentliche Zertifizierungsstellen des Zertifikatmanagers verwenden können, müssen Sie mit den folgenden Konzepten vertraut sein:
ACME-Client. Ein ACME-Client (Automatic Certificate Management Environment) ist ein Client zur Zertifikatsverwaltung, der das ACME-Protokoll verwendet. Ihr ACME-Client muss die externe Kontobindung (EAB) unterstützen, damit er mit einer öffentlichen Zertifizierungsstelle funktioniert.
Externe Kontobindung (External Account Binding, EAB): Sie müssen jedes ACME-Konto, das Sie mit der öffentlichen Zertifizierungsstelle des Zertifikatmanagers verwenden, über die externe Kontobindung an das Google Cloud-Zielprojekt binden. Registrieren Sie dazu jedes ACME-Konto mit einem Secret, das mit dem entsprechenden Google Cloud-Projekt verknüpft ist. Weitere Informationen finden Sie unter Externe Kontobindung.
Herausforderungen für Public CA
Wenn Sie über eine Public CA ein Zertifikat anfordern, werden Sie vom Zertifikatmanager aufgefordert, Ihre Kontrolle über die in diesem Zertifikat aufgeführten Domains nachzuweisen. Sie können die Kontrolle Ihrer Domain beweisen, indem Sie Herausforderungen lösen. Public CA autorisiert die Domainnamen, nachdem Sie Ihre Kontrolle über die Zieldomains nachgewiesen haben.
Nachdem Sie die erforderlichen Autorisierungen erhalten haben, können Sie Zertifikate anfordern, die nur für einen bestimmten Zeitraum gültig sind. Nach diesem Zeitraum müssen Sie den Domainnamen noch einmal validieren. Dazu müssen Sie einen der drei Problemtypen lösen, um weiterhin Zertifikate anfordern zu können.
Typen der Identitätsbestätigung
Public CA unterstützt die folgenden Arten von Identitätsbestätigungen:
HTTP-Abfrage: Bei dieser Aufgabe wird eine Datei an einem bekannten Speicherort auf einem HTTP-Server (Port 80) erstellt, die von Public CA abgerufen und verifiziert werden kann. Weitere Informationen finden Sie unter HTTP-Identitätsbestätigung.
ALPN-Abfrage (TLS-Application Layer Protocol Negotiation): Erfordert einen Server, während einer TLS-Verhandlung an Port 443 ein bestimmtes Zertifikat bereitzustellen, um die Kontrolle über eine Domain nachzuweisen. Weitere Informationen finden Sie unter ACME TLS-ALPN Challenge-Erweiterung.
DNS-Identitätsbestätigung. Erfordert das Hinzufügen eines bestimmten DNS-Eintrags an einem festgelegten Speicherort, um die Kontrolle über eine Domain nachzuweisen. Weitere Informationen finden Sie unter DNS-Abfrage.
Wenn Sie die HTTP- oder TLS-ALPN-Abfrage zum Validieren eines Domainnamens verwenden, kann der Client nur beantragen, dass die validierten Domainnamen in ein Zertifikat aufgenommen werden. Wenn Sie die DNS-Abfrage verwenden, kann der Client auch die Aufnahme von Subdomains dieses Domainnamens in ein Zertifikat anfordern.
Wenn Sie beispielsweise *.myorg.example.com mithilfe der DNS-Abfrage validieren, werden subdomain1.myorg.example.com und subdomain2.myorg.example.com automatisch vom Platzhalterzertifikat abgedeckt. Wenn Sie myorg.example.com jedoch mit einer HTTP- oder TLS-ALPN-Abfrage überprüfen, kann der Client nur anfordern, dass myorg.example.com in das Zertifikat aufgenommen wird, und Sie können *.myorg.example.com nicht mit einer Nicht-DNS-Identitätsbestätigung validieren.
Logik der Herausforderungslösung
Die Abfragelogik der öffentlichen Zertifizierungsstelle sieht so aus:
- Public CA stellt ein zufälliges Token bereit.
- Der Client stellt das Token an einem genau definierten Speicherort zur Verfügung. Der Ort hängt von der Herausforderung ab.
- Der Client gibt der Public CA an, dass er die Aufgabe vorbereitet hat.
- Public CA prüft, ob das Token am erwarteten Speicherort mit dem erwarteten Wert übereinstimmt.
Der Domainname wird autorisiert, nachdem dieser Vorgang abgeschlossen ist. Der Client kann ein Zertifikat mit diesem Domainnamen anfordern. Sie müssen nur eine Herausforderung pro Domainnamen lösen.