Funktionsweise des Zertifikatmanagers

Der Zertifikatmanager verwendet einen flexiblen Zuordnungsmechanismus, mit dem Sie genau steuern können, welche Zertifikate Sie zuweisen und wie sie für die einzelnen Domainnamen in Ihrer Umgebung bereitgestellt werden. Der Mechanismus umfasst die folgenden Entitäten:

  • Zertifikate
  • Zertifikatszuordnungen
  • Zertifikatszuordnungseinträge
  • Domainautorisierungen

Das folgende Diagramm zeigt die Beziehungen zwischen diesen Entitäten für einen typischen Zielproxy, der in einer Weiterleitungsregel für den Load-Balancer angegeben ist:

Zertifikatmanager-Entitäten.
Zertifikatmanager-Entitäten (zum Vergrößern klicken)

Der Zertifikatmanager unterstützt Ziel-HTTPS-Proxys und Ziel-SSL-Proxys. Weitere Informationen zu den Unterschieden zwischen diesen Proxytypen finden Sie unter Zielproxys verwenden.

Informationen zu den Zertifikatstypen, die Certificate Manager unterstützt, finden Sie in der Bereitstellungsübersicht.

Zertifikate

Standardmäßig stellt ein Zertifikat ein einzelnes Zertifikat vom Typ X.509 Transport Layer Security (TLS) (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 über die verknüpfte Domain in Certificate Transparency-Logs, die öffentlich zugänglich sind. Dies ist Teil des standardmäßigen Zertifikatsausstellungsprozesses, der von allen öffentlich vertrauenswürdigen Zertifizierungsstellen verwendet wird, und gilt sowohl für von Google verwaltete Zertifikate als auch für selbstverwaltete Zertifikate. Wenn Sie jedoch den Certificate Authority Service verwenden, um Ihr von Google verwaltetes Zertifikat auszustellen, veröffentlicht Certificate Manager keine Informationen in Certificate Transparency-Logs.

Weitere Informationen finden Sie unter Certificate Transparency.

Informationen zum Bereitstellen eines Zertifikats mit Certificate Manager finden Sie unter Bereitstellungsübersicht.

Von Google verwaltete Zertifikate

Das Verwalten der von Google verwalteten TLS (SSL)-Zertifikate 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 die Ausstellung und Verlängerung von Zertifikaten an den Zertifikatmanager delegieren, damit Sie sich auf andere wichtige Aufgaben konzentrieren können.

Sie können die relevante 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 für eine bestimmte Domain kein Zertifikat von der Google-Zertifizierungsstelle erhalten können, greift der Zertifikatmanager auf die Zertifizierungsstelle Let's Encrypt zurück. Beispielsweise kann die Google-Zertifizierungsstelle die Ausstellung eines Zertifikats für die Domain verweigern oder Ihr CA-Autorisierungseintrag untersagt der Google-Zertifizierungsstelle explizit das Ausstellen von Zertifikaten für diese Domain.

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 (Vorabversion) unterstützen nur die DNS-basierte Autorisierung und erhalten Zertifikate von der Google-Zertifizierungsstelle.

Von Google verwaltete Zertifikate, die von Certificate Authority Service ausgestellt wurden

Wenn Sie Ihre eigene Vertrauenskette verwenden möchten, anstatt sich auf von Google genehmigte öffentliche Zertifizierungsstellen zum Ausstellen Ihrer Zertifikate zu verlassen, können Sie den Zertifikatmanager so konfigurieren, dass stattdessen ein CA-Pool vom Certificate Authority Service als Zertifikatsaussteller verwendet wird. Weitere Informationen zu CA-Pools finden Sie unter CA-Pools erstellen.

Selbstverwaltete Zertifikate

Wenn es in Ihren Geschäftsanforderungen nicht möglich ist, von Google verwaltete Zertifikate zu verwenden, können Sie Zertifikate, die von externen Zertifizierungsstellen ausgestellt wurden, zusammen mit ihren zugehörigen Schlüsseln hochladen. Sie sind dafür verantwortlich, selbstverwaltete Zertifikate manuell auszustellen und zu verlängern.

Mit dem Zertifikatmanager können Sie außerdem 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. In Zertifikatszuordnungseinträgen wird auch die Auswahllogik definiert, 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.

Zertifikatszuordnungseinträge

Ein Eintrag für die Zertifikatszuordnung ist eine Liste von Zertifikaten, die für einen bestimmten Domainnamen bereitgestellt werden. Sie können verschiedene Gruppen von Zertifikaten für verschiedene Domainnamen definieren, z. B. für Domains oder Subdomains. Sie können beispielsweise ein ECDSA- und ein RSA-Zertifikat hochladen und demselben Domainnamen zuordnen. Wenn ein Client eine Verbindung zu diesem Domainnamen herstellt, handelt der Load-Balancer den Zertifikatstyp aus, der während des Handshakes an den Client 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. Erfordert, dass Sie 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. Dies gilt auch für die DNS-Konfiguration für alle Domains, die vom Zertifikat bereitgestellt werden. Funktioniert nicht mit anderen Konfigurationen. Funktioniert mit hochkomplexen Konfigurationen wie anderen Ports als 443 und CDN-Ebenen vor dem Zielproxy.
Bereitstellungsgeschwindigkeit Sie können erst Zertifikate bereitstellen, wenn der Load-Balancer vollständig eingerichtet wurde und Netzwerkverkehr verarbeitet. Sie können Zertifikate im Voraus bereitstellen, bevor der Zielproxy für den Netzwerktraffic bereit ist.

Informationen dazu, wie der Zertifikatmanager die Domaininhaberschaft mit den einzelnen Methoden überprüft, finden Sie unter Domainautorisierungen für von Google verwaltete Zertifikate.

Konfigurationen der Zertifikatsausstellung

Eine Konfiguration für die Zertifikatsausstellung ist eine Ressource, mit der der Zertifikatmanager einen Zertifizierungsstellenpool aus Ihrer eigenen Instanz von Certificate Authority Service verwenden kann, um von Google verwaltete Zertifikate anstelle der Zertifizierungsstelle von Google oder der Zertifizierungsstelle Let's Encrypt auszustellen. Sie können eine Reihe von Parametern angeben, die die Ausstellung und den Ablauf von Zertifikaten steuern, sowie den Schlüsselalgorithmus für Zertifikate auswählen, 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 der gegenseitigen TLS-Authentifizierung darstellt. Es kapselt 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 Ressource der Vertrauenskonfiguration enthält Trust Store, Trust Anchor und Zwischenzertifikatentitäten.

Trust Stores

Ein Trust Store stellt die Konfiguration von Trust-Secrets im Zertifikatmanager zur Verwendung in Szenarien mit gegenseitiger TLS-Authentifizierung dar. Er enthält 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 stellt ein einzelnes Zwischenzertifikat dar, das von einem Root-Zertifikat oder einem Zwischenzertifikat, auf das im kapselnden Trust Store verwiesen wird, zur Verwendung in gegenseitigen TLS-Authentifizierungsszenarien signiert wird.

Abhängig von Ihrer PKI-Konfiguration können ein oder mehrere Zwischenzertifikate in einem Trust Store gekapselt werden. Alle Zwischenzertifikate, die in einer Vertrauenskonfiguration angegeben sind, werden zusätzlich zur Liste der in der Anfrage selbst angegebenen Zwischenzertifikate in die Bewertung der Vertrauensstellung für jede Verbindungsanfrage einbezogen.

Zertifikate, die eine Zulassungsliste erfordern

Wenn Sie ein selbst signiertes, abgelaufenes oder anderweitig ungültiges Zertifikat verwenden müssen oder keinen Zugriff auf das Stamm- und das Zwischenzertifikat haben, können Sie dieses Zertifikat im Feld allowlistedCertificates der Konfiguration der Vertrauensstellung hinzufügen. Sie benötigen keinen Trust Store, um einer Zulassungsliste ein Zertifikat hinzuzufügen.

Wenn Sie der Zulassungsliste ein Zertifikat hinzufügen, gilt das Zertifikat immer als gültig, solange es geparst werden kann, der Besitz eines privaten Schlüssels nachweisbar ist 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:

  1. Ein Client initiiert einen Handshake. Bei diesem Schritt stellt er dem Load-Balancer eine Liste kryptografischer Algorithmen, die zum Ausführen des Handshakes verwendet werden können, und optional eines Hostnamens zur Verfügung.

  2. Der Load-Balancer wählt ein Zertifikat aus, um den sicheren Handshake anhand des vom Client angegebenen Hostnamens und der konfigurierten Zertifikatzuordnungseinträge abzuschließen. Folgende Faktoren bestimmen, welches Zertifikat der Load-Balancer auswählt:

    • 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.com konfiguriert ist, Subdomains der ersten Ebene unter der Domain myorg.example.com ab.

    • 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 kein Hostname übereinstimmt oder kein übereinstimmender Eintrag für eine bereitgestellte Zertifikatszuordnung vorliegt.

    • Handshake-Fehler: Der Handshake schlägt fehl, wenn der Load-Balancer aus den folgenden Gründen kein übereinstimmendes Zertifikat finden kann:

      • 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 in einem Zertifikatzuordnungseintrag anhand folgender Kriterien aus:

  • Zertifikattyp. Wenn der Verbindungsclient die sichereren ECDSA-Zertifikate unterstützt, priorisiert der Load-Balancer sie gegenüber 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 die Zertifikate vom kleinsten zum größten.

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 Elemente im Eintrag definiert sind. Wenn Sie beispielsweise Zertifikatszuordnungseinträge für www.myorg.example.com und *.myorg.example.com konfiguriert haben, wird bei einer Verbindungsanfrage für www.myorg.example.com immer der Eintrag für www.myorg.example.com ausgewählt, auch wenn auch ein Eintrag für *.myorg.example.com vorhanden ist.
  • Platzhalter-Domainnamen stimmen nur bis zu einer Subdomain-Ebene überein. Bei einer Verbindungsanfrage für host1.myorg.example.com wird beispielsweise ein Zertifikatzuordnungseintrag für *.myorg.example.com ausgewählt, aber kein Eintrag für host1.hosts.myorg.example.com.

Public CA

Wenn Sie das Feature für öffentliche Zertifizierungsstellen des Zertifikatmanagers verwenden möchten, 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 Sie mit einer öffentlichen Zertifizierungsstelle arbeiten können.

  • Externe Kontobindung (EAB). Sie müssen jedes ACME-Konto, das Sie mit einer öffentlichen Zertifizierungsstelle des Zertifikatmanagers verwenden, mithilfe der externen Kontobindung an das Google Cloud-Zielprojekt binden. Dazu müssen Sie jedes ACME-Konto mit einem Secret registrieren, das mit dem entsprechenden Google Cloud-Projekt verknüpft ist. Weitere Informationen finden Sie unter Externe Kontobindung.

Herausforderungen der Public CA

Wenn Sie ein Zertifikat über eine Public CA anfordern, werden Sie vom Zertifikatmanager aufgefordert, Ihre Kontrolle über die in diesem Zertifikat aufgeführten Domains nachzuweisen. Sie können die Domainkontrolle nachweisen, 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 eine bestimmte Zeit gültig sind. Nach Ablauf dieser Zeit müssen Sie den Domainnamen noch einmal validieren, indem Sie einen 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. Dazu muss eine Datei an einem bekannten Speicherort auf einem HTTP-Server (Port 80) erstellt werden, die Public CA abrufen und überprüfen kann. Weitere Informationen findest du unter HTTP-Abfrage.

  • TLS-Application Layer Protocol Negotiation (ALPN): Erfordert, dass ein Server während einer TLS-Verhandlung auf Port 443 ein bestimmtes Zertifikat bereitstellt, um die Kontrolle über eine Domain nachzuweisen. Weitere Informationen finden Sie unter ACME TLS-ALPN Challenge Extension.

  • DNS-Abfrage: Erfordert das Hinzufügen eines spezifischen DNS-Eintrags an einem festgelegten 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 eines Domainnamens verwenden, kann der Client nur die Aufnahme der bestätigten Domainnamen in ein Zertifikat anfordern. Wenn Sie die DNS-Abfrage verwenden, kann der Client auch Subdomains dieses Domainnamens anfordern, die in ein Zertifikat aufgenommen werden sollen.

Wenn Sie beispielsweise *.myorg.example.com mit der DNS-Abfrage validieren, werden subdomain1.myorg.example.com und subdomain2.myorg.example.com automatisch durch das Platzhalterzertifikat abgedeckt. Wenn Sie myorg.example.com jedoch mit einer HTTP- oder TLS-ALPN-Abfrage validieren, kann der Client nur die Aufnahme von myorg.example.com in das Zertifikat anfordern 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:

  1. Public CA stellt ein zufälliges Token bereit.
  2. Der Client stellt das Token an einem klar definierten Standort zur Verfügung. Der Ort hängt von der jeweiligen Herausforderung ab.
  3. Der Client gibt der Public CA an, dass er die Herausforderung vorbereitet hat.
  4. Public CA prüft, ob das am erwarteten Speicherort vorhandene Token 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 pro Domainname nur eine Aufgabe lösen.