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.
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 Anwendungs-Load-Balancern, regionalen internen Anwendungs-Load-Balancern und regionalen externen Anwendungs-Load-Balancern werden Zertifikate von Certificate Manager an den Zielproxy angehängt. Zertifikatzuordnungen werden nicht unterstützt.
Weitere Informationen erhalten Sie in dieser Dokumentation:
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 jeder Application Load Balancer die verschiedenen Methoden zur Zertifikatskonfiguration unterstützt.
Compute Engine-SSL-Zertifikate
Die folgende Tabelle zeigt, welche Google Cloud-Load-Balancer selbstverwaltete Compute Engine-SSL-Zertifikate oder 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.
Zertifikatmanager-SSL-Zertifikate
Die folgende Tabelle zeigt, welche Google Cloud-Load-Balancer selbstverwaltete Zertifikate von Certificate Manager, von Google verwaltete Zertifikate oder beides unterstützen.
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 Zertifikatzuordnung. 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.
Zertifikatsauswahlmethode
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.
Sie können den Prozess modellieren, mit dem Google Cloud-Proxy-Load-Balancer ein Zertifikat auswählen, das an einen Client gesendet werden soll. Beginnen Sie in Ihrem Modell mit allen SSL-Zertifikaten, die auf dem Ziel-HTTPS-Proxy oder dem Ziel-SSL-Proxy konfiguriert wurden, unabhängig von der Konfigurationsmethode.
Der Load-Balancer wählt einen einzelnen Zertifikatskandidaten aus:
Wenn der Zielproxy eines Load-Balancers nur auf eine Compute Engine-SSL-Zertifikatsressource verweist oder der Zielproxy eines Load-Balancers auf eine Certificate Manager-Zuordnung mit nur einem Zertifikatseintrag verweist, verwendet der Load-Balancer das einzige als Zertifikatskandidaten konfigurierte Zertifikat. 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-Zertifikatsressourcen verweist oder wenn der Zielproxy eines Load-Balancers auf eine Certificate Manager-Zuordnung mit zwei oder mehr Zertifikatseinträgen verweist, wendet der Load-Balancer folgenden Prozess für die Auswahl eines einzelnen Zertifikatskandidaten an:
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 CNdogs.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 CNcats.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.
- Wenn der angegebene SNI-Hostname
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
undnotValidAfter
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