SSL-Zertifikate

SSL/TLS ist das am häufigsten verwendete kryptografische Protokoll im Internet. Technisch gesehen ist TLS der Nachfolger von SSL, obwohl die Begriffe manchmal synonym verwendet werden, wie in diesem Dokument.

Transport Layer Security (TLS) wird verwendet, um Informationen zu verschlüsseln, während sie über ein Netzwerk gesendet werden. Dadurch wird der Datenschutz zwischen einem Client und einem Server oder Load-Balancer sichergestellt. Google Cloud-Proxy-Load-Balancer, deren Weiterleitungsregeln auf einen Ziel-HTTPS-Proxy oder Ziel-SSL-Proxy verweisen, benötigen einen privaten Schlüssel und ein SSL-Zertifikat als Teil der Zielproxy-Konfiguration des Load-Balancers.

Hinweis: Auf dieser Seite werden SSL-Zertifikate im Kontext der Verschlüsselung bei der Übertragung zwischen einem Google Cloud-Proxy-Load-Balancer und (nachgelagerten) Clients beschrieben, die eine Verbindung zum Google Cloud-Load-Balancer herstellen. Weitere Informationen zur Verschlüsselung bei der Übertragung zwischen dem Google Cloud-Load-Balancer und seinen vorgelagerten Back-Ends finden Sie im Artikel Verschlüsselung der Back-Ends.

Methoden der Zertifikatskonfiguration

Google Cloud bietet zwei Methoden zum Konfigurieren von SSL-Zertifikaten für HTTP(S)- und SSL-Proxy-Load-Balancer. Beide Methoden unterstützen selbstverwaltete und von Google verwaltete SSL-Zertifikate.

• Compute Engine-SSL-Zertifikatsressource: Bei dieser Methode ist der Zielproxy für einen globalen externen Application Load Balancer, klassischen Application Load Balancer, externe Proxy-Network Load Balancer, regionaler externer Application Load Balancer oder der interne Application Load Balancer ist so konfiguriert, dass er auf eine Compute Engine-SSL-Zertifikatsressource verweist. Die SSL-Zertifikatsressource enthält den privaten Schlüssel, das entsprechende Zertifikat und optional auch CA-Zertifikate. Diese Methode unterstützt alle Netzwerkdienststufen, die vom Load-Balancer unterstützt werden.

• Zertifikatmanager: Bei dieser Methode ist der Zielproxy für einen globalen externen Application Load Balancer, klassischen Application Load Balancer oder einen externen Proxy-Network Load Balancer so konfiguriert, dass er auf eind Zertifikatszuordnung verweist. Die Zertifikatzuordnung enthält einen oder mehrere Zertifikatseinträge. Jeder Zertifikatseintrag verweist auf eine einzelne Certificate Manager-Zertifikatsressource und jede Zertifikatsressource enthält einen privaten Schlüssel und ein Zertifikat. Mit Certificate Manager kann ein Ziel-HTTPS-Proxy oder ein Ziel-SSL-Proxy auf eine Zertifikatszuordnung mit Tausenden von SSL-Zertifikatseinträgen verweisen. Diese Methode ist nur verfügbar, wenn der Load-Balancer die Premium-Netzwerkdienststufe verwendet.

  Bei regionenübergreifenden internen Application Load Balancern, regionalen internen Application Load Balancern und regionalen externen Application Load Balancern werden Certificate Manager-Zertifikate an den Ziel-Proxy angehängt. Zertifikatszuordnungen werden nicht unterstützt.

  Weitere Informationen erhalten Sie in dieser Dokumentation:

  • Certificate Manager – Übersicht
  • Bereitstellungsübersicht

In der folgenden Tabelle sind die verschiedenen Arten von Zertifikatsressourcen aufgeführt, die entweder an einen HTTPS-Zielproxy oder einen SSL-Zielproxy von Google Cloud-Proxy-Load Balancern angehängt werden können. Compute Engine-SSL-Zertifikate werden direkt mit dem Zielproxy verknüpft, während Certificate Manager-SSL-Zertifikate entweder direkt mit dem Zielproxy oder über eine Zertifikatszuordnung verknüpft werden können.

Hinweis:

Sie können dem Zielproxy entweder ein Compute Engine-SSL-Zertifikat oder ein Certificate Manager-SSL-Zertifikat zuweisen, aber nicht beides.

Wenn Sie dem Zielproxy ein Compute Engine-SSL-Zertifikat und gleichzeitig Zertifikate über eine Zertifikatszuordnung zuordnen, verwendet der Proxy die Zertifikate, auf die in der Zertifikatszuordnung verwiesen wird, und ignoriert das direkt angehängte TLS-Zertifikat (SSL).

Proxy-Load-Balancer	Compute Engine-SSL-Zertifikate	SSL-Zertifikate von Certificate Manager
		Über eine Zertifikatszuordnung mit dem Zielproxy verknüpft	Direkt an den Zielproxy angehängt
Globaler externer Application Load Balancer (mit einem HTTPS-Proxy)
Klassischer Application Load Balancer (mit einem HTTPS-Proxy)
Globaler externer Proxy-Network Load Balancer (mit einem SSL-Proxy)
Klassischer Proxy-Network Load Balancer (mit SSL-Proxy)
Regionsübergreifender interner Application Load Balancer (mit einem HTTPS-Proxy)
Regionaler externer Application Load Balancer (mit einem HTTPS-Proxy)
Regionaler interner Application Load Balancer (mit einem HTTPS-Proxy)

Zertifikat-Typen

Sie können eigene Zertifikate erstellen oder von Google verwalten lassen:

• Selbstverwaltete SSL-Zertifikate sind Zertifikate, die Sie selbst beziehen, bereitstellen und verlängern. Selbstverwaltete Zertifikate können jeden der folgenden Zertifikatstypen für öffentliche Schlüssel haben:

  • Domain Validation (DV)
  • Organization Validation (OV)
  • Extended Validation (EV)

  Selbstverwaltete SSL-Zertifikate verwenden.

  Selbstverwaltetes Zertifikat hochladen in der Dokumentation zu Certificate Manager oder Selbstverwaltetes Zertifikat bereitstellen für eine End-to-End-Anleitung.

• Von Google verwaltete SSL-Zertifikate sind Zertifikate, die Google Cloud automatisch abruft, verwaltet und verlängert. Von Google verwaltete Zertifikate sind immer DV-Zertifikate (Domain Validation). Sie zeigen nicht die Identität einer Organisation oder Person, die mit dem Zertifikat verknüpft ist, und sie unterstützen keine allgemeinen Namen für Platzhalter.

  Von Google verwaltete SSL-Zertifikate verwenden.

  Certificate Manager unterstützt von Google verwaltete SSL-Zertifikate mithilfe der Load-Balancer-Autorisierung, der DNS-Autorisierung und der Einbindung in einen Certificate Authority Service. Weitere Informationen zu Certificate Manager für von Google verwaltete SSL-Zertifikate finden Sie in der Dokumentation zu Certificate Manager Bereitstellungsübersicht.

Zertifikate und Google Cloud-Load-Balancer

In den folgenden Abschnitten wird beschrieben, wie die einzelnen Application Load Balancer die verschiedenen Methoden zur Zertifikatskonfiguration unterstützen.

Compute Engine-SSL-Zertifikate

In der folgenden Tabelle sehen Sie, welche Google Cloud-Load Balancer selbstverwaltete Compute Engine-SSL-Zertifikate, von Google verwaltete Compute Engine-SSL-Zertifikate oder beides unterstützen:

	Unterstützung von Compute Engine-SSL-Zertifikaten
Load-Balancer	Selbstverwaltet	Von Google verwaltet
Globaler externer Application Load Balancer ^*	sslCertificates	sslCertificates
Klassischer Application Load Balancer ^*	sslCertificates	sslCertificates
Regionaler externer Application Load Balancer ^†	regionSslCertificates
Regionaler interner Application Load Balancer ^†	regionSslCertificates
Regionsübergreifender interner Application Load Balancer ^*
Externer Proxy-Network Load Balancer (mit SSL-Proxy) ^‡	sslCertificates	sslCertificates

---

^* Der globale externe Application Load Balancer, regionenübergreifende interne Application Load Balancer und der klassische Application Load Balancer verwenden globale Ziel-HTTPS-Proxys, auch wenn ein klassischer Application Load Balancer die Standardstufe verwendet.

^† Der regionale externe Application Load Balancer und der interne Application Load Balancer verwenden regionale HTTPS-Zielproxys.

^‡ Der externe Proxy-Network Load Balancer verwendet globale Ziel-SSL-Proxys, auch in der Standard-Stufe.

SSL-Zertifikate von Certificate Manager

Die folgende Tabelle zeigt, welche Google Cloud-Load-Balancer selbstverwaltete Zertifikate von Certificate Manager, von Google verwaltete Zertifikate oder beides unterstützen.

Hinweis: Bei regionenübergreifenden internen Application Load Balancern, regionalen internen Application Load Balancern und regionalen externen Application Load Balancern werden Certificate Manager-Zertifikate (sowohl von Google verwaltete als auch selbstverwaltete) an den Ziel-Proxy angehängt. Zertifikatszuordnungen werden nicht unterstützt.

Load-Balancer	Von Google verwaltetes Zertifikat			Selbstverwaltetes Zertifikat
	DNS-Autorisierung	Load-Balancer-Autorisierung	Certificate Authority Service (CA Service)
Globaler externer Application Load Balancer	info	info	info	info
Klassischer Application Load Balancer	info	info	info	info
Globaler externer Proxy-Network Load Balancer	info	info	info	info
Regionsübergreifender interner Application Load Balancer	info		info	info
Regionaler externer Application Load Balancer	info		info	info
Regionaler interner Application Load Balancer	info		info	info

Mehrere SSL-Zertifikate

Sie können denselben Ziel-HTTPS-Proxy oder Ziel-SSL-Proxy zum Hosten mehrerer Zertifikate verwenden. Das ist üblich, wenn der Load-Balancer mehrere Domainnamen unterstützt. Sie können eine einzelne Weiterleitungsregel (eine einzelne IP-Adresse und einen Port) so konfigurieren, dass sie auf einen gemeinsamen Zielproxy verweist. Sie können auch mehrere Weiterleitungsregeln (unterschiedliche IP-Adressen und Ports) so konfigurieren, dass sie auf einen gemeinsamen Zielproxy verweisen.

Mehrere SSL-Zertifikatsressourcen von Compute Engine

Bei Verwendung von Compute Engine-SSL-Zertifikatsressourcen kann jede Zielproxy-Ressource auf eine nicht konfigurierbare maximale Anzahl von SSL-Zertifikaten pro Ziel-HTTPS- oder Ziel-SSL-Proxy verweisen. Weitere Informationen finden Sie in der Dokumentation zu Load-Balancing-Kontingenten und -Limits im Artikel Zielpools und Zielproxys.

Die erste Compute Engine-SSL-Zertifikatsressource, auf die der Zielproxy eines Load-Balancers verweist, gilt als das standardmäßige (primäre) Zertifikat des Load-Balancers.

Mehrere SSL-Zertifikate von Certificate Manager

Wenn Sie Certificate Manager mit einer Zertifikatszuordnung auf einem Load Balancer verwenden, verweist jede Zielproxy-Ressource auf eine einzelne Zertifikatszuordnung. Eine Zertifikatzuordnung verweist auf einen oder mehrere Zertifikatseinträge. Sie können konfigurieren, welcher Zertifikatseintrag das Standardzertifikat (primäres Zertifikat) für die Zuordnung ist. Die Anzahl der Zuordnungen, Einträge und Certificate Manager-Zertifikate sind als Kontingente pro Projekt konfigurierbar. Weitere Informationen finden Sie in der Dokumentation zu Certificate Manager im Artikel Ressourcenkontingente.

Wenn Sie einen Load-Balancer verwenden, der Certificate Manager unterstützt, und Sie mehr als ein paar SSL-Zertifikate pro Zielproxy hosten müssen, sollten Sie statt der Compute Engine-SSL-Zertifikatressourcen den Certificate Manager verwenden.

Hinweis: Bei regionenübergreifenden internen Application Load Balancern, regionalen internen Application Load Balancern und regionalen externen Application Load Balancern werden Certificate Manager-Zertifikate an den Ziel-Proxy angehängt. Zertifikatszuordnungen werden nicht unterstützt.

Zertifikatsauswahlmethode

Hinweis: Die in diesem Abschnitt beschriebene Methode zur Zertifikatsauswahl gilt für Zertifikate, die direkt an einen Zielproxy angehängt sind. Wenn Ihr Zielproxy jedoch zusätzlich zu den Compute Engine-SSL-Zertifikaten, die direkt mit einem Zielproxy verknüpft sind, über eine Zertifikatszuordnung auf Zertifikate verweist, werden die Compute Engine-SSL-Zertifikate ignoriert und der Proxy verwendet die Zertifikate, auf die in der Zertifikatszuordnung verwiesen wird. Die Auswahllogik für Zertifikate, auf die über eine Zertifikatszuordnung verwiesen wird, wird im Abschnitt Logik für die Zertifikatsauswahl der Certificate Manager-Dokumentation beschrieben.

Nachdem ein Client eine Verbindung zu einem HTTP(S)- oder SSL-Proxy-Load-Balancer hergestellt hat, handeln der Client und der Load-Balancer eine TLS-Sitzung aus. Während der Verhandlung von TLS-Sitzungen sendet der Client dem Load-Balancer eine Liste der unterstützten TLS-Chiffren (in ClientHello). Der Load-Balancer wählt ein Zertifikat aus, dessen Algorithmus für öffentliche Schlüssel mit dem Client kompatibel ist. Der Client kann im Rahmen dieser Verhandlung auch einen SNI-Hostnamen (Server Name Indication) an den Load-Balancer senden. SNI-Hostnamendaten werden manchmal verwendet, um dem Load-Balancer bei der Auswahl des Zertifikats zu helfen, das an den Client gesendet werden soll.

Google Cloud-Proxy-Load Balancer folgen den in diesem Abschnitt beschriebenen Schritten, um ein Zertifikat auszuwählen und an den Client zu senden. Der Begriff „standardmäßiges (primäres) SSL-Zertifikat“, wie er in den folgenden Schritten verwendet wird, bezieht sich auf das erste Compute Engine-SSL-Zertifikat, auf das der Zielproxy verweist.

1. Der Load-Balancer wählt einen einzelnen Zertifikatskandidaten aus:

   • Wenn der Zielproxy eines Load Balancers nur auf eine Compute Engine-SSL-Zertifikatsressource verweist, verwendet der Load Balancer das einzige konfigurierte Zertifikat als Zertifikatskandidaten. Der Wert des SNI-Hostnamens (falls angegeben) hat keinen Einfluss auf den Load-Balancer. Fahren Sie mit Schritt 2 fort.

   • Wenn der Zielproxy eines Load Balancers auf zwei oder mehr Compute Engine-SSL-Zertifikatressourcen verweist, wählt der Load Balancer anhand des folgenden Verfahrens einen einzelnen Zertifikatskandidaten aus:

     • Wenn der Client keinen SNI-Hostnamen in seiner ClientHello sendet, verwendet der Load-Balancer das standardmäßige (primäre) SSL-Zertifikat als Zertifikatskandidaten. Fahren Sie mit Schritt 2 fort.

     • Wenn der Client einen SNI-Hostnamen sendet, der nicht mit einem allgemeinen Zertifikatsnamen (CN) und mit keinem alternativen Zertifikatsnamen (SAN) übereinstimmt, verwendet der Load-Balancer das standardmäßige (primäre) SSL-Zertifikat als Zertifikatskandidaten. Fahren Sie mit Schritt 2 fort.

     • Der Load-Balancer wählt einen Zertifikatskandidaten aus, der dem vom Client gesendeten SNI-Hostnamen entspricht. Der Abgleich erfolgt mit dem längsten Präfix gegen den allgemeinen Zertifikatsnamen (CN) und den alternativen Zertifikatsnamen (SAN), wobei ECDSA-Zertifikate gegenüber RSA-Zertifikaten bevorzugt werden. Betrachten Sie zur Veranschaulichung der Abgleichsmethode einen Zielproxy, der auf ein Zertifikat verweist, dessen CN cats.pets.example.com ist, und auf ein anderes Zertifikat, dessen CN dogs.pets.example.com ist. Jedes Zertifikat enthält nicht nur jeden CN-Wert in seinen SANs, sondern auch *.pets.example.com und *.example.com.

       • Wenn der angegebene SNI-Hostname cats.pets.example.com lautet, verwendet der Load-Balancer das Zertifikat, dessen CN cats.pets.example.com ist, als Zertifikatskandidat. Fahren Sie mit Schritt 2 fort.
       • Wenn der angegebene SNI-Hostname ferrets.pets.example.com lautet, verwendet der Load-Balancer eines der beiden Zertifikate als Zertifikatskandidaten, da beide konfigurierten Zertifikate SANs mit dem folgenden Inhalt haben: *.pets.example.com. In diesem Fall können Sie nicht steuern, welches der beiden Zertifikate zum Kandidaten wird. Fahren Sie mit Schritt 2 fort.

2. Der Zertifikatskandidat wird an den Client gesendet, wenn der Zertifikatskandidat einen öffentlichen Schlüsselalgorithmus verwendet, der mit einer der vom Client angegebenen Chiffren kompatibel ist.

   • Die TLS-Verhandlung kann fehlschlagen, wenn der Client keine Cipher Suite unterstützt, die den öffentlichen Schlüsselalgorithmus (ECDSA oder RSA) des Zertifikats enthält.
   • Der Load-Balancer verwendet die Attribute notValidBefore und notValidAfter des Zertifikats nicht als Teil der Kandidatenauswahlmethode. Der Load-Balancer kann beispielsweise ein abgelaufenes Zertifikat bereitstellen, wenn das abgelaufene Zertifikat als Zertifikatskandidaten ausgewählt wurde.

Preise

Bei der Verwendung von Google Cloud-Load-Balancern fallen Netzwerkgebühren an. Weitere Informationen finden Sie unter Alle Netzwerkpreise. Informationen zu Preisen für Certificate Manager finden Sie in der Dokumentation zu Certificate Manager. Für die Verwendung von Compute Engine-SSL-Zertifikatsressourcen fallen keine zusätzlichen Gebühren an.

Nächste Schritte

• Weitere Informationen zu Compute Engine-SSL-Zertifikaten finden Sie auf den folgenden Seiten:

  • Selbstverwaltete SSL-Zertifikate verwenden.
  • Von Google verwaltete SSL-Zertifikate verwenden.
  • Informationen zu Kontingenten und Limits (einschließlich der unterstützten Schlüssellängen) für Compute Engine-SSL-Zertifikate finden Sie unter SSL-Zertifikate und Zielpools und Ziel-Proxys in der Dokumentation zum Load-Balancer.

• Weitere Informationen zu Certificate Manager finden Sie auf den folgenden Seiten:

  • Certificate Manager – Übersicht
  • Selbstverwaltetes Zertifikat hochladen in der Dokumentation zu Certificate Manager oder Selbstverwaltetes Zertifikat bereitstellen für eine End-to-End-Anleitung.
  • Weitere Informationen zu von Google verwalteten SSL-Zertifikaten und Certificate Manager finden Sie in der Dokumentation zu Certificate Manager im Artikel Zertifikate verwalten.
  • Informationen zu Kontingenten und Limits für Certificate Manager finden Sie in der Dokumentation zu Certificate Manager im Artikel Ressourcenkontingente.

• Weitere Informationen zum Konfigurieren von SSL-Zertifikaten für Proxy-Load-Balancer, die von GKE verwaltet werden, finden Sie im Artikel GKE Ingress für HTTP(S)-Load-Balancing, in der GKE Gateway API-Dokumentation und im Artikel Containernatives Load-Balancing über eigenständige zonale NEGs.

• Weitere Informationen zu Load-Balancern und der Verschlüsselung während der Übertragung finden Sie im Whitepaper Verschlüsselung der Back-Ends und Verschlüsselung bei der Übertragung in Google Cloud.

Überzeugen Sie sich selbst

Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie einfach ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

Jetzt kostenlos starten