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. Ein Application Load Balancer oder Proxy-Network-Load-Balancer, der SSL verwendet, benötigt mindestens einen privaten Schlüssel und ein SSL-Zertifikat.

Auf dieser Seite werden SSL-Zertifikate und die Verschlüsselung bei der Übertragung zwischen einem Application Load Balancer oder Proxy-Network-Load-Balancer, der SSL verwendet, und seinen Clients erläutert. Weitere Informationen zur Verschlüsselung bei der Übertragung zwischen dem Google Cloud Load Balancer und seinen Backends finden Sie unter Verschlüsselung der Backends.

Methoden der Zertifikatskonfiguration

Google Cloud bietet drei Methoden zur Zertifikatskonfiguration für Application Load Balancer, die HTTPS-Zielproxys verwenden, und Proxy-Network Load Balancer, die SSL-Zielproxys verwenden.

  • Zielproxy verweist auf Compute Engine-SSL-Zertifikate: Bei dieser Methode kann der Zielproxy des Load Balancers auf bis zu 15 Compute Engine-SSL-Zertifikatsressourcen verweisen. Jede SSL-Zertifikatsressource von Compute Engine enthält den privaten Schlüssel, das entsprechende Zertifikat und optional auch CA-Zertifikate.

  • Ziel-Proxy verweist auf eine Zertifikatszuordnung des Zertifikatmanagers: Bei dieser Methode verweist der Ziel-Proxy des Load Balancers auf eine einzelne Zertifikatszuordnung. Die Zertifikatszuordnung unterstützt standardmäßig Tausende von Einträgen und kann auf Millionen von Einträgen skaliert werden. Jeder Eintrag enthält Daten zum privaten Schlüssel und zum Zertifikat.

  • Ziel-Proxy verweist direkt auf Zertifikatmanager-Zertifikate: Bei dieser Methode kann der Ziel-Proxy des Load Balancers auf bis zu 100 Zertifikatmanager-Zertifikate verweisen.

Load-Balancer-Unterstützung

In der folgenden Tabelle sehen Sie, welche Methoden zur Zertifikatskonfiguration von den einzelnen Load Balancern unterstützt werden.

Load-Balancer Methode der Zertifikatskonfiguration
Compute Engine-SSL-Zertifikate Zertifikatmanager (Zertifikatszuordnung) Zertifikatmanager (einzelne Zertifikate)
Application Load Balancer (HTTPS-Zielproxys)
Globaler externer Application Load Balancer Selbstverwaltet
Von Google verwaltet 		Selbstverwaltet
Von Google verwaltet
Klassischer Application Load Balancer Selbstverwaltet
Von Google verwaltet 		Selbstverwaltet
Von Google verwaltet
Regionaler externer Application Load Balancer Selbstverwaltet
Von Google verwaltet 		Selbstverwaltet
Von Google verwaltet
Regionaler interner Application Load Balancer Selbstverwaltet
Von Google verwaltet 		Selbstverwaltet
Von Google verwaltet
Regionsübergreifender interner Application Load Balancer Selbstverwaltet
Von Google verwaltet
Proxy-Network-Load-Balancer (Ziel-SSL-Proxys)
Globaler externer Proxy-Network Load Balancer Selbstverwaltet
Von Google verwaltet 		Selbstverwaltet
Von Google verwaltet
Klassischer Proxy-Network Load Balancer Selbstverwaltet
Von Google verwaltet 		Selbstverwaltet
Von Google verwaltet

Regeln für Konfigurationsmethoden

Google Cloud erzwingt die folgenden Regeln für die Zertifikatskonfigurationsmethode:

  • Für Load Balancer, die sowohl Compute Engine-SSL-Zertifikate als auch Certificate Manager-Zertifikatszuordnungen unterstützen: Der Ziel-Proxy des Load Balancers kann gleichzeitig auf eine Zertifikatszuordnung und ein oder mehrere Compute Engine-SSL-Zertifikate verweisen.

  • Für Load Balancer, die sowohl Compute Engine-SSL-Zertifikate als auch direkt angehängte Zertifikate des Zertifikatmanagers unterstützen: Der Ziel-Proxy des Load Balancers kann nur so konfiguriert werden, dass er auf bis zu 15 Compute Engine-SSL-Zertifikate oder bis zu 100 Zertifikate des Zertifikatmanagers verweist, nicht auf eine Kombination aus beiden.

Zertifikat-Typen

Google Cloud unterstützt sowohl selbstverwaltete als auch von Google verwaltete Zertifikate.

Selbstverwaltete SSL-Zertifikate

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

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

Sie können selbstverwaltete SSL-Zertifikate mit folgenden Tools erstellen:

Von Google verwaltete SSL-Zertifikate

Von Google verwaltete SSL-Zertifikate sind Zertifikate, die Google Cloudautomatisch 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.

Von Google verwaltete Zertifikate mit Platzhaltern werden vom Zertifikatmanager nur bei Verwendung der DNS-Autorisierung unterstützt.

Sie können von Google verwaltete SSL-Zertifikate mit folgenden Tools erstellen:

  • Compute Engine-SSL-Zertifikatsressourcen: Nur globale Compute Engine-sslCertificates-Ressourcen unterstützen von Google verwaltete SSL-Zertifikate. regionSslCertificates unterstützen sie nicht. Globale Compute Engine-SSL-Zertifikate unterstützen nur öffentlich vertrauenswürdige, von Google verwaltete Zertifikate. Weitere Informationen finden Sie unter Von Google verwaltete SSL-Zertifikate verwenden.
  • Zertifikatmanager: Zertifikatmanager-Zertifikate (sowohl global als auch regional) unterstützen sowohl öffentlich vertrauenswürdige von Google verwaltete Zertifikate als auch privat vertrauenswürdige von Google verwaltete Zertifikate. Weitere Informationen finden Sie in der Dokumentation zu Zertifikatmanager im Artikel Zertifikate.

Unterstützte Schlüsseltypen

Load Balancer unterstützen Zertifikate, die private Schlüssel verschiedener Schlüsseltypen verwenden. In der folgenden Tabelle sehen Sie, welche Schlüsseltypen unterstützt werden, je nachdem, ob die Zertifikate global oder regional sind und ob sie selbstverwaltet oder von Google verwaltet werden.
SSL-Zertifikatstyp arrow_forward

Schlüsseltyp arrow_downward 		Compute Engine-SSL-Zertifikate Zertifikatmanager-SSL-Zertifikate
Global Regional Global und regional
Selbstverwaltet Öffentlich vertrauenswürdig, von Google verwaltet Selbstverwaltet Selbstverwaltet Öffentlich vertrauenswürdig, von Google verwaltet Privat vertrauenswürdig, von Google verwaltet
RSA-2048
RSA-3072
RSA-4096
ECDSA P-256
ECDSA P-384
Weitere Informationen zu Zertifikaten des Zertifikatmanagers finden Sie in der Dokumentation zum Zertifikatmanager.

Zertifikate mit ECDSA-Schlüsseln verwenden

In diesem Abschnitt wird erläutert, warum wir ECDSA gegenüber RSA als Best Practice für Zertifikatsignaturschlüssel empfehlen.

Welcher Schlüsseltyp verwendet werden soll

ECDSA P-256 ist der empfohlene Schlüsseltyp für die meisten TLS-Zertifikate. Er bietet eine starke kryptografische Sicherheit sowie eine hervorragende Leistung für Signaturvorgänge und eine effiziente Nutzung der Netzwerkbandbreite.

Mögliche Gründe für die Verwendung anderer Zertifikatschlüsseltypen:

  • Wenn Sie Legacy-Clients unterstützen müssen, die keine ECDSA-Zertifikate unterstützen, können Sie zusätzlich zu ECDSA-P-256-Zertifikaten RSA-2048-Zertifikate bereitstellen.
  • Wenn Sie bestimmte Compliance-Anforderungen haben, die größere Schlüsselgrößen oder bestimmte Schlüsseltypen erfordern, können Sie ECDSA P-384-, RSA-2048-, RSA-3072- und RSA-4096-Schlüssel verwenden.

Vorteile von ECDSA gegenüber RSA

Der Hauptvorteil von ECDSA liegt in der Fähigkeit, ein gleichwertiges kryptografisches Sicherheitsniveau mit deutlich kleineren Schlüsseln im Vergleich zu RSA zu bieten. Diese Effizienz führt zu spürbaren Leistungs- und Ressourcenvorteilen. Ein kleinerer Schlüssel bedeutet nicht, dass die Sicherheit geringer ist. ECDSA basiert auf dem diskreten Logarithmusproblem der elliptischen Kurve, das eine höhere Sicherheit pro Schlüsseleinheit und in einigen Fällen eine bessere Recheneffizienz im Vergleich zu RSA bietet.

Beispiel:

  • Ein 256-Bit-ECDSA-Schlüssel bietet ein ähnliches Sicherheitsniveau wie ein RSA-3072-Schlüssel.
  • Ein 384-Bit-ECDSA-Schlüssel bietet ein höheres Sicherheitsniveau als jede weitgehend unterstützte RSA-Schlüsselgröße.

Wichtigste Vorteile von ECDSA:

  • Leistung: ECDSA-Signaturvorgänge sind deutlich weniger rechenintensiv als RSA-Vorgänge mit einem gleichwertigen Sicherheitsniveau. Dadurch werden CPU-Last und Latenz reduziert, was für Systeme mit hohem Durchsatz oder latenzempfindliche Systeme entscheidend ist.

  • Effizienz: Kleinere Schlüssel und Signaturen erfordern weniger Bandbreite und Speicherplatz, was besonders in ressourcenbeschränkten Umgebungen wie Mobil- und IoT-Geräten von Vorteil ist.

Mehrere SSL-Zertifikate

Ein Application Load Balancer oder Proxy-Network Load Balancer kann zwei oder mehr SSL-Zertifikate gleichzeitig hosten, wenn sein Ziel-Proxy mit einer unterstützten Zertifikatskonfigurationsmethode konfiguriert ist. Als Best Practice sollten Sie den Zertifikatmanager verwenden, wenn mehrere SSL-Zertifikate erforderlich sind.

  • Für Load Balancer, die Compute Engine-SSL-Zertifikate unterstützen: Der Ziel-Proxy des Load Balancers kann auf bis zu 15 Compute Engine-SSL-Zertifikate verweisen. Die erste referenzierte Compute Engine-SSL-Zertifikatsressource ist das standardmäßige (primäre) Zertifikat für den Ziel-Proxy.

  • Für Load Balancer, die eine Zertifikatszuordnung des Zertifikatmanagers unterstützen: Der Ziel-Proxy des Load Balancers verweist auf eine einzelne Zertifikatszuordnung. Die Zertifikatszuordnung unterstützt Tausende von Zertifikatszuordnungseinträgen. Sie können konfigurieren, welcher Zertifikatseintrag das Standardzertifikat (primäres Zertifikat) für die Zertifikatszuordnung ist.

  • Für Load Balancer, die das direkte Verweisen auf Zertifikate des Zertifikatmanagers unterstützen: Der Ziel-Proxy des Load Balancers kann auf bis zu 100 Zertifikate des Zertifikatmanagers verweisen. Die erste referenzierte SSL-Zertifikatsressource des Zertifikatmanagers ist das Standardzertifikat (primäre Zertifikat) für den Ziel-Proxy.

Weitere Informationen finden Sie unter:

Zertifikatsauswahlprozess

Der folgende Zertifikatsauswahlprozess gilt für Load Balancer, deren Ziel-Proxys auf mehrere Compute Engine-SSL-Zertifikate oder mehrere Zertifikatmanager-Zertifikate verweisen.

Der Zertifikatsauswahlprozess ist anders, wenn der Ziel-Proxy eines Load Balancers auf eine Zertifikatszuordnung des Zertifikatmanagers verweist. Weitere Informationen zum Zertifikatsauswahlprozess einer Zertifikatszuordnung finden Sie in der Dokumentation zu Certificate Manager im Artikel Logik für Zertifikatsauswahl.

Nachdem ein Client eine Verbindung zum 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.

  • Wenn der Ziel-Proxy des Load Balancers nur auf ein Zertifikat verweist, wird dieses Zertifikat verwendet und der Wert des vom Client gesendeten SNI-Hostnamens ist nicht relevant.

  • Wenn der Zielproxy des Load Balancers auf zwei oder mehr Zertifikate verweist, verwendet der Load Balancer den folgenden Prozess, um ein einzelnes Zertifikat auszuwählen:

    • Wenn der Client keinen SNI-Hostnamen in seiner ClientHello gesendet hat, verwendet der Load Balancer das erste Zertifikat in seiner Zertifikatsliste.

    • 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 erste Zertifikat in seiner Zertifikatsliste.

    • In allen anderen Situationen wählt der Load Balancer ein Zertifikat mithilfe des folgenden Abgleichprozesses aus:

      • Der Abgleich erfolgt sowohl mit dem allgemeinen Zertifikatsnamen (CN) als auch mit dem alternativen Zertifikatsnamen (SAN). Domainnamen in den CN- und SAN-Attributen dürfen nur Kleinbuchstaben enthalten. Zertifikate mit Großbuchstaben in Domainnamen werden nur zurückgegeben, wenn sie als primäres Zertifikat im Ziel-Proxy festgelegt wurden.

        Wenn nur ein Zertifikat mit dem SNI-Hostnamen übereinstimmt, wählt der Load Balancer dieses Zertifikat aus. Wenn mehrere Zertifikate mit dem SNI-Hostnamen übereinstimmen, priorisiert der Load Balancer sie in der folgenden Reihenfolge:

        • Genaue Hostnamenübereinstimmung: Genaue Übereinstimmungen mit dem CN oder SAN haben Vorrang vor Platzhalterübereinstimmungen.

        • Platzhalter-Hostnamen-Übereinstimmung: Wenn keine genaue Übereinstimmung vorliegt, sucht der Load Balancer nach einer Platzhalter-CN- oder SAN-Übereinstimmung. Ein Platzhalter (*) stimmt nur mit der Subdomain der ersten Ebene überein (z. B. stimmt *.pets.example.com mit cats.pets.example.com und nicht mit *.example.com überein).

        • Zertifikatsschlüsseltyp: ECDSA-Zertifikate werden gegenüber RSA-Zertifikaten bevorzugt.

        • Größe der Zertifikatskette: Wenn mehrere Zertifikate dieselbe Übereinstimmungsspezifität und denselben Algorithmus für öffentliche Schlüssel haben, priorisiert der Load Balancer das Zertifikat mit der kleineren Zertifikatskette (in Byte), um die Netzwerkbandbreite während des TLS-Handshakes zu minimieren.

      • Betrachten Sie zur Veranschaulichung der Abgleichsmethode einen Zielproxy, der auf die folgenden beiden Zertifikate verweist:

        • Zertifikat A

          • CN: cats.pets.example.com
          • SANs: cats.pets.example.com, *.pets.example.com, *.example.com

        • Zertifikat B

          • CN: dogs.pets.example.com
          • SANs: dogs.pets.example.com, *.pets.example.com, *.example.com

      • Betrachten Sie nun die folgenden Szenarien:

        • Wenn der vom Client gesendete SNI-Hostname cats.pets.example.com lautet, verwendet der Load Balancer Zertifikat A.

        • Wenn der vom Client gesendete SNI-Hostname ferrets.pets.example.com lautet, gibt es keine genaue Übereinstimmung und sowohl Zertifikat A als auch Zertifikat B stimmen mit *.pets.example.com in ihrer SAN-Liste überein. Wenn beide Zertifikate denselben Algorithmus für öffentliche Schlüssel verwenden, wählt der Load Balancer das Zertifikat mit der kleineren Zertifikatskette aus. Wenn die Größe der Zertifikatsketten ebenfalls identisch ist, wählt der Load-Balancer entweder Zertifikat A oder Zertifikat B aus. Sie können nicht steuern, welches Zertifikat ausgewählt wird.

  • Nachdem ein Zertifikat ausgewählt wurde, sendet der Load Balancer dem Client dieses Zertifikat nur dann, wenn das ausgewählte Zertifikat einen Algorithmus für öffentliche Schlüssel verwendet, der mit einer vom Client in der ClientHello gesendeten Chiffre kompatibel ist. Die TLS-Verhandlung schlägt fehl, wenn der Client keine Cipher Suite unterstützt, die den Algorithmus für öffentliche Schlüssel (ECDSA oder RSA) des vom Load Balancer ausgewählten Zertifikats enthält.

Preise

Informationen zu den Preisen für Compute Engine-SSL-Zertifikate und Cloud Load Balancing finden Sie unter Netzwerkpreise: Cloud Load Balancing.

Informationen zu den Preisen für den Zertifikatmanager finden Sie auf der Preisseite für den Zertifikatmanager.

Nächste Schritte

Überzeugen Sie sich selbst

Wenn Sie mit Google Cloudnoch 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