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 Cloud de Confiance Load Balancer und seinen Backends finden Sie unter Verschlüsselung der Backends.

Methode der Zertifikatskonfiguration

Bei Application Load Balancern, die HTTPS-Zielproxys verwenden, muss der Ziel-Proxy des Load Balancers auf ein bis 15 Compute Engine-SSL-Zertifikate verweisen. Jede SSL-Zertifikatsressource von Compute Engine enthält den privaten Schlüssel, das entsprechende Zertifikat und optional auch CA-Zertifikate.

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)
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

Zertifikat-Typen

Sie können selbstverwaltete SSL-Zertifikate für Ihre Load Balancer erstellen.

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 mithilfe von Compute Engine-SSL-Zertifikatsressourcen erstellen. Weitere Informationen finden Sie unter Selbstverwaltete SSL-Zertifikate verwenden.

Unterstützte Schlüsseltypen

Die folgenden Schlüsseltypen werden für regionale selbstverwaltete Compute Engine-SSL-Zertifikate unterstützt:

  • RSA-2048
  • RSA-3072
  • RSA-4096
  • ECDSA P-256
  • ECDSA P-384

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

Der Ziel-Proxy eines Application 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.

Weitere Informationen finden Sie in der Load-Balancing-Dokumentation unter Zielproxys und SSL-Zertifikate.

Zertifikatsauswahlprozess

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

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). 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.

Nächste Schritte