Funktionsweise des Zertifikatmanagers

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:

<ph type="x-smartling-placeholder">
</ph> Zertifikatmanager-Entitäten.
Zertifikatmanager-Entitäten (zum Vergrößern klicken)

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

Informationen zu den Zertifikatstypen, die im Zertifikatmanager finden Sie unter 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.

Der Zertifikatmanager unterstützt die folgenden Arten von Zertifikaten:

  • 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 verknüpften Domain in Certificate Transparency-Protokollen, öffentlich zugänglich sind. Dies ist Teil der standardmäßigen Zertifikatsausstellung und gilt sowohl für von Google verwaltete Zertifikate und selbstverwaltete Zertifikate. Wenn Sie jedoch den Certificate Authority Service nutzen, von Google verwaltetes Zertifikat, der Zertifikatmanager veröffentlicht keine in Certificate Transparency-Protokollen.

Weitere Informationen finden Sie unter Certificate Transparency:

Informationen zum Bereitstellen eines Zertifikats mit dem Zertifikatmanager Siehe 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 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. Zertifikatmanager unterstützt RSA Von Google verwaltete 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 kann, Der Zertifikatmanager greift auf die Zertifizierungsstelle „Let's Encrypt“ 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 (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 zu verlassen Um Ihre Zertifikate auszustellen, können Sie den Zertifikatmanager so konfigurieren, dass ein Zertifizierungsstellenpool von Certificate Authority Service als Zertifikatsaussteller. 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. In Zertifikatszuordnungseinträgen wird auch Die Auswahllogik, der der Load-Balancer beim Einrichten des Clients folgt Verbindungen. 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, stellt der Load-Balancer die Zertifikate bereit, die diesem Hostnamen zugeordnet sind. 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. Du kannst beispielsweise einen ECDSA und eine RSA hochladen. Zertifikat und ordnen sie demselben Domainnamen zu. Wenn ein Client eine Verbindung zu handelt, handelt das Lastenausgleichsmodul den Zertifikatstyp für die Bereitstellung den Client während des Handshakes.

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 Ihrem 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 ist und Netzwerkverkehr bereitstellt. 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) darstellt im Zertifikatmanager zur Verwendung bei Szenarien mit gegenseitiger TLS-Authentifizierung. Es enthält einen einzelnen Trust Store, der wiederum einen Trust-Anchor und optional ein oder mehrere Zwischenzertifikate

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 steht für ein einzelnes signiertes Zwischenzertifikat. durch ein Root-Zertifikat oder ein Zwischenzertifikat, auf das im Kapselung von Trust Store zur Verwendung in der gegenseitigen TLS-Authentifizierung Szenarien durchführen.

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, die eine Zulassungsliste erfordern

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:

  1. Ein Client initiiert einen Handshake. Bei diesem Schritt wird der Load-Balancer mit einer Liste kryptografischer Algorithmen, mit denen der Handshake abgeschlossen werden kann, und optional einen Hostnamen.

  2. 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.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 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 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 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 bis zum größten Wert.

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 z. B. Zertifikatszuordnungseinträge für www.myorg.example.com und *.myorg.example.com, eine Verbindungsanfrage für www.myorg.example.com wählt immer den Eintrag für www.myorg.example.com aus, auch wenn ein Eintrag für *.myorg.example.com ist auch vorhanden.
  • Platzhalter-Domainnamen stimmen nur bis zu einer Subdomain-Ebene überein. Für Beispiel: Bei einer Verbindungsanfrage für host1.myorg.example.com wird ein Zertifikat ausgewählt. Karteneintrag für *.myorg.example.com, aber nicht einen für host1.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 (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 ein Zertifikat über eine Public CA anfordern, Im Zertifikatmanager werden Sie aufgefordert, Ihre Kontrolle über die Domains nachzuweisen die in diesem Zertifikat aufgeführt sind. Sie können die Domainkontrolle nachweisen, indem Sie Herausforderungen lösen. Public CA autorisiert die Domainnamen, nachdem Sie Ihre Kontrolle über die Zieldomains.

Nachdem Sie die erforderlichen Autorisierungen erhalten haben, können Sie Zertifikate anfordern, die nur für einen bestimmten Zeitraum. 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 findest du 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-Abfrage validieren, subdomain1.myorg.example.com und subdomain2.myorg.example.com sind automatisch abgedeckt durch das Platzhalterzertifikat. 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:

  1. Public CA stellt ein zufälliges Token bereit.
  2. Der Client stellt das Token an einem klar definierten Standort zur Verfügung. Die ist von der jeweiligen Herausforderung abhängig.
  3. Der Client gibt der Public CA an, dass er den Herausforderung.
  4. 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.