Selbstverwaltete SSL-Zertifikate verwenden

Selbstverwaltete SSL-Zertifikate sind solche, die Sie selbst beziehen, bereitstellen und erneuern. Sie können diese Ressource verwenden, um die Kommunikation zwischen Clients und Ihrem Load-Balancer zu sichern.

Selbstverwaltete Zertifikate können eine beliebige Kombination der folgenden Zertifikatstypen sein:

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

Selbstverwaltete Zertifikate werden von den folgenden Load-Balancern unterstützt:

• Globale Zertifikate
  • Globalen externen Application Load Balancern
  • Klassischer Application Load Balancer
  • Externen Proxy-Network Load Balancern (mit einem Ziel-SSL-Proxy)
• Regionale Zertifikate
  • Regionalen externen Application Load Balancern
  • Interner Application Load Balancer

Auf dieser Seite wird beschrieben, wie Sie ein gültiges Compute Engine-Zertifikat beziehen und anschließend hochladen, um eine Google Cloud SSL-Zertifikatsressource zu erstellen.

Informationen zum Erstellen von von Google verwalteten Zertifikaten mit Certificate Manager finden Sie in der Bereitstellungsübersicht.

Hinweis:

Hinweis: Informationen zu selbstverwalteten Zertifikaten für GKE Ingress finden Sie unter HTTPS (TLS) zwischen Client und Load Balancer einrichten im Dokument „Ingress für externe Application Load Balancer“.

Hinweise

• Sie sollten mit den Inhalten in der Übersicht über SSL-Zertifikate vertraut sein.
• Achten Sie darauf, dass Sie die Domainnamen haben, die Sie für Ihr selbstverwaltetes SSL-Zertifikat verwenden möchten. Wenn Sie Cloud Domains verwenden, lesen Sie Schritt 1: Domainnamen mit Cloud Domains registrieren.

Berechtigungen

Um die Aufgaben in dieser Anleitung ausführen zu können, müssen Sie SSL-Zertifikate in Ihrem Projekt erstellen und ändern können. Dies ist möglich, wenn eine der folgenden Aussagen zutrifft:

• Sie sind Projektinhaber oder Projektbearbeiter (roles/owner oder roles/editor).
• Sie haben im Projekt sowohl die Rolle „Compute-Sicherheitsadministrator“ (compute.securityAdmin) als auch die Rolle „Compute-Netzwerkadministrator“ (compute.networkAdmin).
• Sie haben eine benutzerdefinierte Rolle für das Projekt, die einerseits die Berechtigungen compute.sslCertificates.* und andererseits, je nach verwendetem Load-Balancer-Typ, eine der oder die beiden Berechtigungen compute.targetHttpsProxies.* und compute.targetSslProxies.* enthält.

Schritt 1: Privaten Schlüssel und Zertifikat erstellen

Wenn Sie bereits einen privaten Schlüssel und ein Zertifikat einer Zertifizierungsstelle (Certificate Authority, CA) haben, überspringen Sie diesen Abschnitt und fahren Sie mit Schritt 2: Selbstverwaltete SSL-Zertifikatsressource erstellen fort.

Privaten Schlüssel auswählen oder erstellen

Ein Google Cloud-SSL-Zertifikat enthält sowohl einen privaten Schlüssel als auch das Zertifikat selbst, beide im PEM-Format. Ihr privater Schlüssel muss die folgenden Kriterien erfüllen:

• Er muss das PEM-Format haben.
• Er darf nicht durch eine Passphrase geschützt sein. Google Cloud speichert Ihren privaten Schlüssel in einem eigenen verschlüsselten Format.
• Der Verschlüsselungsalgorithmus muss RSA-2048 oder ECDSA P-256 sein.

Verwenden Sie zum Erstellen eines neuen privaten Schlüssels einen der folgenden OpenSSL-Befehle.

• Erstellen Sie einen privaten RSA-2048-Schlüssel:

  openssl genrsa -out PRIVATE_KEY_FILE 2048
  

• Erstellen Sie einen privaten ECDSA P-256-Schlüssel:

  openssl ecparam -name prime256v1 -genkey -noout -out PRIVATE_KEY_FILE
  

Ersetzen Sie PRIVATE_KEY_FILE durch den Pfad und den Dateinamen der neuen privaten Schlüsseldatei.

Anfrage für das Signieren des Zertifikats (Certificate Signing Request, CSR) erstellen

Nachdem Sie einen privaten Schlüssel erstellt haben, können Sie mit OpenSSL eine Anfrage zum Signieren eines Zertifikats (Certificate Signing Request, CSR) im PEM-Format generieren. Die CSR muss dabei die folgenden Kriterien erfüllen:

• Sie muss im PEM-Format vorliegen.
• Sie muss ein Attribut für einen gemeinsamen Namen (CN) oder ein Attribut für einen alternativen Antragstellernamen (SAN) haben. Im Prinzip sollte das Zertifikat beide Attribute, also CN und SAN, enthalten, auch wenn es sich um eine einzelne Domain handelt – moderne Clients wie z. B. aktuelle Versionen von macOS und iOS stützen sich nicht allein auf das Attribut CN.

So erstellen Sie eine CSR:

1. Erstellen Sie eine OpenSSL-Konfigurationsdatei. Im folgenden Beispiel werden alternative Antragstellernamen in [sans_list] definiert.

   cat <<'EOF' >CONFIG_FILE
   [req]
   default_bits              = 2048
   req_extensions            = extension_requirements
   distinguished_name        = dn_requirements
   prompt                    = no
   
   [extension_requirements]
   basicConstraints          = CA:FALSE
   keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
   subjectAltName            = @sans_list
   
   [dn_requirements]
   countryName               = Country Name (2 letter code)
   stateOrProvinceName       = State or Province Name (full name)
   localityName              = Locality Name (eg, city)
   0.organizationName        = Organization Name (eg, company)
   organizationalUnitName    = Organizational Unit Name (eg, section)
   commonName                = Common Name (e.g. server FQDN or YOUR name)
   emailAddress              = Email Address
   
   [sans_list]
   DNS.1                     = SUBJECT_ALTERNATIVE_NAME_1
   DNS.2                     = SUBJECT_ALTERNATIVE_NAME_2
   
   EOF
   

2. Führen Sie den folgenden OpenSSL-Befehl aus, um eine CSR-Datei zu erstellen. Der Befehl ist interaktiv, d. h. Sie werden zur Eingabe von Attributen aufgefordert. Das gilt nicht für den alternativen Antragstellernamen, den Sie in der [sans_list] der CONFIG_FILE im vorherigen Schritt definiert haben.

   openssl req -new -key PRIVATE_KEY_FILE \
       -out CSR_FILE \
       -config CONFIG_FILE
   

Ersetzen Sie in beiden Schritten Folgendes:

• CONFIG_FILE: Der Pfad, einschließlich des Dateinamens, für die OpenSSL-Konfigurationsdatei. Sie können die Datei löschen, nachdem Sie diesen Vorgang abgeschlossen haben.

• SUBJECT_ALTERNATIVE_NAME_1 und SUBJECT_ALTERNATIVE_NAME_2: Alternative Antragstellernamen für Ihr Zertifikat.

  Wenn das Zertifikat nur für einen Hostnamen gilt, sollten Sie nur einen alternativen Antragstellernamen angeben, der mit dem gemeinsamen Namen übereinstimmt. Wenn Sie mehr als zwei alternative Antragstellernamen benötigen, fügen Sie diese der Konfigurationsdatei hinzu und erhöhen Sie jeweils die Zahl nach DNS (DNS.3, DNS.4 usw.).

• PRIVATE_KEY_FILE: Der Pfad zur privaten Schlüsseldatei.

• CSR_FILE: Der Pfad, einschließlich des Dateinamens, zur CSR.

CSR signieren

Wenn eine Zertifizierungsstelle Ihre CSR signiert, verwendet sie für die Erstellung des Zertifikats ihren eigenen privaten Schlüssel: Verwenden Sie eine der folgenden Methoden, um den CSR zu signieren:

Öffentlich vertrauenswürdige Zertifizierungsstelle verwenden

Wenn Sie Ihre CSR von einer öffentlich vertrauenswürdigen Zertifizierungsstelle signieren lassen, wird das Zertifikat von allen Clients, die dieser öffentlichen Zertifizierungsstelle vertrauen, als vertrauenswürdig eingestuft. Zum Erstellen eines signierten Zertifikats benötigt die öffentliche Zertifizierungsstelle nur die CSR.

Eigene interne Zertifizierungsstelle verwenden

Wenn Sie eine eigene Zertifizierungsstelle verwalten, können Sie damit Ihre CSR signieren. So wird ein intern vertrauenswürdiges Zertifikat erstellt, wenn Ihre Clients ebenfalls so konfiguriert wurden, dass sie Ihrer eigenen Zertifizierungsstelle vertrauen.

Selbst signiertes Zertifikat verwenden

Wenn Sie zum Signieren der CSR denselben privaten Schlüssel verwenden, den Sie auch zum Erstellen der CSR verwendet haben, haben Sie ein selbst signiertes Zertifikat erstellt. Sie sollten selbst signierte Zertifikate nur zu Testzwecken verwenden.

Google Cloud unterstützt keine clientseitige Überprüfung für selbst signierte Serverzertifikate. Daher müssen Sie den Client so konfigurieren, dass er die Zertifikatvalidierung überspringt. Sie können beispielsweise einen Webbrowser-Client erstellen, der eine Nachricht anzeigt, in der Sie gefragt werden, ob Sie einem selbst signierten Zertifikat vertrauen möchten.

Wenn Sie Ihre eigene Zertifizierungsstelle verwalten oder ein selbst signiertes Zertifikat für Tests erstellen möchten, können Sie den folgenden OpenSSL-Befehl verwenden:

openssl x509 -req \
    -signkey PRIVATE_KEY_FILE \
    -in CSR_FILE \
    -out CERTIFICATE_FILE \
    -extfile CONFIG_FILE \
    -extensions extension_requirements \
    -days TERM

Ersetzen Sie Folgendes:

• PRIVATE_KEY_FILE: Der Pfad zum privaten Schlüssel für Ihre Zertifizierungsstelle. Wenn Sie ein selbst signiertes Zertifikat für Testzwecke erstellen, ist dieser private Schlüssel der gleiche, den Sie auch zum Erstellen der CSR verwendet haben.
• CSR_FILE: Der Pfad zur CSR.
• CERTIFICATE_FILE: Der Pfad zur Zertifikatsdatei, die erstellt werden soll.
• TERM: Die Anzahl der Tage ab heute, während denen das Zertifikat von Clients, die es prüfen, als gültig eingestuft werden soll.

Platzhalter in gemeinsamen Namen

In den selbstverwalteten SSL-Zertifikaten können Sie im gemeinsamen Namen einen Platzhalter verwenden. Ein Zertifikat mit dem gemeinsamen Namen *.example.com. stimmt zum Beispiel mit den Hostnamen www.example.com und foo.example.com, aber nicht mit a.b.example.com oder example.com überein. Wenn der Load-Balancer ein Zertifikat auswählt, bevorzugt er Zertifikate, die mit einem Hostnamen ohne Platzhalter übereinstimmen, gegenüber Zertifikaten mit Platzhaltern.

Zertifikate mit Platzhalterfragmenten wie f*.example.com werden nicht unterstützt.

Schritt 2: Selbstverwaltete SSL-Zertifikatsressource erstellen

Für das Erstellen einer Google Cloud-SSL-Zertifikatsressource benötigen Sie einen privaten Schlüssel und ein Zertifikat. Sollten Sie diese noch nicht erstellt haben, lesen Sie die Informationen unter Schritt 1: Privaten Schlüssel und Zertifikat erstellen.

Console

Sie können globale SSL-Zertifikate auf dem Tab Klassische Zertifikate der Google Cloud Console verwenden. Regionale SSL-Zertifikate können nicht in der Google Cloud Console erstellt werden. Verwenden Sie entweder gcloud oder die REST API.

Hinweis: Folgende Vorgehensweise führt Sie direkt zum Tab Klassische Zertifikate. Sie finden den Tab Klassische Zertifikate auf der Seite Zertifikatmanager, die über die Seite der obersten Ebene Sicherheit verknüpft ist.

1. Rufen Sie in der Google Cloud Console den Tab Klassische Zertifikate auf.
   Zu den Klassischen Zertifikaten
2. Klicken Sie auf SSL-Zertifikat erstellen.
3. Geben Sie einen Namen und optional eine Beschreibung für das Zertifikat ein.
4. Wählen Sie Zertifikat hochladen aus.
5. Fügen Sie Ihr Zertifikat ein oder klicken Sie auf Hochladen und suchen Sie nach Ihrer Zertifikatsdatei.
   Sie können die CA-Zertifikatskette in dieselbe Datei wie das Zertifikat aufnehmen. Google Cloud validiert die Zertifikatskette nicht für Sie. Die Validierung liegt in Ihrer Verantwortung.
6. Fügen Sie Ihren privaten Schlüssel ein oder klicken Sie auf Hochladen und suchen Sie nach Ihrer privaten Schlüsseldatei.
7. Klicken Sie auf Erstellen.

gcloud

Verwenden Sie zum Erstellen eines globalen SSL-Zertifikats den Befehl gcloud compute ssl-certificates create mit dem Flag --global:

gcloud compute ssl-certificates create CERTIFICATE_NAME \
    --certificate=CERTIFICATE_FILE \
    --private-key=PRIVATE_KEY_FILE \
    --global

Verwenden Sie zum Erstellen eines regionalen SSL-Zertifikats den Befehl gcloud compute ssl-certificates create mit dem Flag --region:

gcloud compute ssl-certificates create CERTIFICATE_NAME \
    --certificate=CERTIFICATE_FILE \
    --private-key=PRIVATE_KEY_FILE \
    --region=REGION

Dabei gilt:

• CERTIFICATE_NAME: Der Name der globalen Zertifikatsressource, die erstellt werden soll.

• CERTIFICATE_FILE: Der Pfad zu einer Zertifikatsdatei im PEM-Format.

  Sie können die CA-Zertifikatskette in dieselbe Datei wie das Zertifikat aufnehmen. Google Cloud validiert die Zertifikatskette nicht für Sie. Die Validierung liegt in Ihrer Verantwortung.

• PRIVATE_KEY_FILE: Der Pfad zu einem privaten Schlüssel im PEM-Format. Der private Schlüssel darf nicht durch eine Passphrase geschützt sein

• REGION: Gegebenenfalls die Region für das regionale SSL-Zertifikat.

  Wenn diese Zertifikatsressource entweder für einen internen Application Load Balancer oder für einen regionalen externen Application Load Balancer vorgesehen ist, muss die Region mit der Region des Load Balancers übereinstimmen.

API

Bevor Sie die API-Methoden verwenden können, müssen Sie zuerst das Zertifikat und die privaten Schlüsseldateien lesen, da die API-Anfrage den Inhalt der Dateien senden muss.

Lesen Sie die Zertifikat- und privaten Schlüsseldateien und erstellen Sie dann das SSL-Zertifikat. Die folgenden Beispiele zeigen, wie das mit Python funktioniert.

Verwenden Sie für globale SSL-Zertifikate die API-Methode sslCertificates.insert:

from pathlib import Path
from pprint import pprint
from typing import Union

from googleapiclient import discovery


def create_certificate(
    project_id: str,
    certificate_file: Union[str, Path],
    private_key_file: Union[str, Path],
    certificate_name: str,
    description: str = "Certificate created from a code sample.",
) -> dict:
    """
    Create a global SSL self-signed certificate within your Google Cloud project.

    Args:
        project_id: project ID or project number of the Cloud project you want to use.
        certificate_file: path to the file with the certificate you want to create in your project.
        private_key_file: path to the private key you used to sign the certificate with.
        certificate_name: name for the certificate once it's created in your project.
        description: description of the certificate.

    Returns:
        Dictionary with information about the new global SSL self-signed certificate.
    """
    service = discovery.build("compute", "v1")

    # Read the cert into memory
    with open(certificate_file) as f:
        _temp_cert = f.read()

    # Read the private_key into memory
    with open(private_key_file) as f:
        _temp_key = f.read()

    # Now that the certificate and private key are in memory, you can create the
    # certificate resource
    ssl_certificate_body = {
        "name": certificate_name,
        "description": description,
        "certificate": _temp_cert,
        "privateKey": _temp_key,
    }
    request = service.sslCertificates().insert(
        project=project_id, body=ssl_certificate_body
    )
    response = request.execute()
    pprint(response)
    return response

Verwenden Sie für regionale SSL-Zertifikate die API-Methode regionSslCertificates.insert:

from pathlib import Path
from pprint import pprint
from typing import Union

from googleapiclient import discovery


def create_regional_certificate(
    project_id: str,
    region: str,
    certificate_file: Union[str, Path],
    private_key_file: Union[str, Path],
    certificate_name: str,
    description: str = "Certificate created from a code sample.",
) -> dict:
    """
    Create a regional SSL self-signed certificate within your Google Cloud project.

    Args:
        project_id: project ID or project number of the Cloud project you want to use.
        region: name of the region you want to use.
        certificate_file: path to the file with the certificate you want to create in your project.
        private_key_file: path to the private key you used to sign the certificate with.
        certificate_name: name for the certificate once it's created in your project.
        description: description of the certificate.

        Returns:
        Dictionary with information about the new regional SSL self-signed certificate.
    """
    service = discovery.build("compute", "v1")

    # Read the cert into memory
    with open(certificate_file) as f:
        _temp_cert = f.read()

    # Read the private_key into memory
    with open(private_key_file) as f:
        _temp_key = f.read()

    # Now that the certificate and private key are in memory, you can create the
    # certificate resource
    ssl_certificate_body = {
        "name": certificate_name,
        "description": description,
        "certificate": _temp_cert,
        "privateKey": _temp_key,
    }
    request = service.regionSslCertificates().insert(
        project=project_id, region=region, body=ssl_certificate_body
    )
    response = request.execute()
    pprint(response)

    return response

Weitere Codebeispiele finden Sie auf der API-Referenzseite.

Schritt 3: SSL-Zertifikat mit einem Zielproxy verknüpfen

Sie müssen jedem HTTPS- oder SSL-Zielproxy mindestens ein SSL-Zertifikat zuordnen. Sie können den Zielproxy maximal mit der Höchstzahl der SSL-Zertifikate pro HTTPS- oder SSL-Zielproxy konfigurieren. Mehrere selbstverwaltete Zertifikate können auf denselben Zielproxy verweisen.

Hinweis: Wenn Sie ein vorhandenes SSL-Zertifikat ersetzen, erstellen Sie zuerst das Ersatz-SSL-Zertifikat und ordnen es dem Zielproxy des Load-Balancers zu, bevor Sie das alte SSL-Zertifikat löschen.

Console

Wenn Sie einen vorhandenen Load-Balancer mit der Google Cloud Console bearbeiten, verknüpfen Sie das SSL-Zertifikat automatisch mit dem entsprechenden Zielproxy.

gcloud

Wenn Sie ein globales SSL-Zertifikat mit einem HTTPS-Zielproxy verknüpfen möchten, verwenden Sie den Befehl gcloud compute target-https-proxies update mit den Flags --global und --global-ssl-certificates:

gcloud compute target-https-proxies update TARGET_PROXY_NAME \
    --global \
    --ssl-certificates=SSL_CERTIFICATE_LIST \
    --global-ssl-certificates

Verwenden Sie den Befehl gcloud compute target-ssl-proxies update, um ein globales SSL-Zertifikat mit einem SSL-Zielproxy zu verknüpfen:

gcloud compute target-ssl-proxies update TARGET_PROXY_NAME \
    --ssl-certificates=SSL_CERTIFICATE_LIST

Wenn Sie ein regionales SSL-Zertifikat mit einem HTTPS-Zielproxy verknüpfen möchten, verwenden Sie den Befehl gcloud compute target-https-proxies update mit den Flags --region und --ssl-certificates-region:

gcloud compute target-https-proxies update TARGET_PROXY_NAME \
    --region=REGION \
    --ssl-certificates=SSL_CERTIFICATE_LIST \
    --ssl-certificates-region=REGION

Dabei gilt:

• TARGET_PROXY_NAME: Der Name des Zielproxys des Load-Balancers.
• REGION (falls zutreffend): die Region für den regionalen Zielproxy und das regionale SSL-Zertifikat; Die Regionen müssen übereinstimmen

• SSL_CERTIFICATE_LIST: Eine durch Kommas getrennte Liste der Namen von Google Cloud SSL-Zertifikaten.

  Die Liste der referenzierten Zertifikate muss alle älteren gültigen SSL-Zertifikate sowie das neue SSL-Zertifikat enthalten. Der Befehl gcloud compute target-ssl-proxies update überschreibt die ursprünglichen Werte für --ssl-certificates durch den neuen Wert.

API

Wenn Sie ein globales SSL-Zertifikat mit einem HTTPS-Zielproxy verknüpfen möchten, senden Sie eine POST-Anfrage an die Methode targetHttpsProxies.insert und ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/targetHttpsProxy

{
"name": "l7-xlb-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-xlb-map",
"sslCertificates": /projectsPROJECT_IDglobal/sslCertificates/SSL_CERT_NAME
}

Wenn Sie ein globales SSL-Zertifikat mit einem HTTPS-Zielproxy verknüpfen möchten, senden Sie eine POST-Anfrage an die Methode targetSslProxies.insert und ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/targetSslProxy

{
"name": "l7-ssl-proxy",
"sslCertificates": /projectsPROJECT_IDglobal/sslCertificates/SSL_CERT_NAME
}

Wenn Sie ein regionales SSL-Zertifikat mit einem HTTPS-Zielproxy verknüpfen möchten, senden Sie eine POST-Anfrage an die Methode targetHttpsProxies.insert und ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/targetHttpsProxy

{
"name": "l7-xlb-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-map",
"region": "us-west1"
"sslCertificates": /projectsPROJECT_IDregions/us-west1/sslCertificates/SSL_CERT_NAME
}

Schritt 4: DNS-A- und AAAA-Einträge aktualisieren, sodass sie auf die IP-Adresse des Load-Balancers verweisen

Fügen Sie die DNS-A-Einträge (für IPv4) und die DNS-AAAA-Einträge (für IPv6) für Ihre Domains und Subdomains auf der Website Ihres Registrators, DNS-Hosts oder Internetanbieters (abhängig davon, wo Ihre DNS-Einträge verwaltet werden) hinzu oder aktualisieren Sie sie dort. Die Einträge müssen auf die IP-Adresse verweisen, die der Weiterleitungsregel oder den Weiterleitungsregeln des Load-Balancers zugeordnet ist.

Wenn Sie Cloud DNS und Cloud Domains verwenden, richten Sie Ihre Domains ein und aktualisieren Sie Ihre Nameserver.

Wenn Sie mehrere Domains für ein einzelnes Zertifikat verwenden, müssen Sie DNS-Einträge für alle Domains und Subdomains hinzufügen oder aktualisieren, sodass sie alle auf die IP-Adresse Ihres Load-Balancers verweisen.

Wichtig: Achten Sie darauf, dass der Domainname direkt zur IP-Adresse des externen Application Load Balancers aufgelöst wird. Er darf nicht zu einer anderen IP-Adresse aufgelöst werden, auch wenn diese andere IP-Adresse Antworten für den Load-Balancer weitergibt, weiterleitet oder im Cache speichert. Sie können beispielsweise keine selbstverwalteten Zertifikate verwenden, wenn Ihr Domainname zur externen IP-Adresse eines CDN-Drittanbieters aufgelöst wird.

Nachdem die DNS-Weitergabe abgeschlossen wurde, können Sie die Einrichtung mit dem Befehl dig prüfen. Angenommen, Ihre Domain ist www.example.com. Führen Sie folgenden dig-Befehl aus:

dig www.example.com

; <<>> DiG 9.10.6 <<>> www.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31748
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.example.com.           IN  A

;; ANSWER SECTION:
www.example.com.        1742    IN  CNAME   www.example.com.edgekey.net.
www.example.com.edgekey.net. 21330 IN   CNAME   www.example.com.edgekey.net.globalredir.akadns.net.
www.example.com.edgekey.net.globalredir.akadns.net. 3356 IN CNAME   e6858.dsce9.akamaiedge.net.
e6858.dsce9.akamaiedge.net. 19  IN  A   203.0.113.5

;; Query time: 43 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Jun 03 16:54:44 PDT 2020
;; MSG SIZE  rcvd: 193

In diesem Beispiel ist 203.0.113.5 die IP-Adresse Ihres Load-Balancers.

Schritt 5: Mit OpenSSL testen

Es kann bis zu 30 Minuten dauern, bis der Load-Balancer Ihr selbstverwaltetes SSL-Zertifikat verwendet.

Führen Sie zum Testen den folgenden OpenSSL-Befehl aus. Ersetzen Sie dabei DOMAIN durch Ihren DNS-Namen und IP_ADDRESS durch die IP-Adresse Ihres Load-Balancers.

echo | openssl s_client -showcerts -servername DOMAIN -connect IP_ADDRESS:443 -verify 99 -verify_return_error

Dieser Befehl gibt die Zertifikate aus, die der Load-Balancer dem Client anbietet. Neben anderen detaillierten Informationen sollte die Ausgabe die Zertifikatskette und Verify return code: 0 (ok) enthalten.

Mit selbstverwalteten SSL-Zertifikaten arbeiten

In den folgenden Abschnitten wird beschrieben, wie Sie SSL-Zertifikatsressourcen auflisten, aufrufen, löschen und ersetzen.

SSL-Zertifikate auflisten

Console

Sie können den Status Ihrer globalen SSL-Zertifikate auf dem Tab Klassische Zertifikate der Seite Zertifikatmanager prüfen. Regionale SSL-Zertifikate können in der Google Cloud Console nicht verwaltet werden. Verwenden Sie entweder gcloud oder die REST API.

1. Rufen Sie in der Google Cloud Console den Tab „Klassische Zertifikate” auf.
   Zu den Klassischen Zertifikaten
2. (Optional) Filtern Sie die Liste der SSL-Zertifikate.

gcloud

Verwenden Sie zum Auflisten globaler SSL-Zertifikate den Befehl gcloud compute ssl-certificates list mit dem Flag --global:

gcloud compute ssl-certificates list \
   --global

Verwenden Sie zum Auflisten regionaler SSL-Zertifikate den Befehl gcloud compute ssl-certificates list mit dem Filter region:

gcloud compute ssl-certificates list \
   --filter="region:(REGION ...)"

Dabei gilt:

• REGION: Eine Google Cloud-Region; mehrere Regionen als durch Leerzeichen getrennte Liste einschließen.

SSL-Zertifikate beschreiben

Console

Weitere Details zu Ihren globalen SSL-Zertifikaten finden Sie auf der Seite Zertifikatmanager auf dem Tab Klassische Zertifikate.

1. Rufen Sie in der Google Cloud Console die Seite „Klassische Zertifikate” auf.
   Zu den Klassischen Zertifikaten
2. (Optional) Filtern Sie die Liste der SSL-Zertifikate.
3. Klicken Sie auf den Zertifikatsnamen, um weitere Details abzurufen.

gcloud

Verwenden Sie zum Beschreiben eines globalen SSL-Zertifikats den Befehl gcloud compute ssl-certificates describe mit dem Flag --global:

gcloud  compute ssl-certificates describe CERTIFICATE_NAME \
   --global

Verwenden Sie zum Beschreiben eines regionalen SSL-Zertifikats den Befehl gcloud compute ssl-certificates describe mit dem Flag --region:

gcloud compute ssl-certificates describe CERTIFICATE_NAME \
   --region=REGION

Dabei gilt:

• CERTIFICATE_NAME: Der Name des SSL-Zertifikats.
• REGION: Eine Google Cloud-Region.

Hinweis: Bei der Beschreibung eines vorhandenen Zertifikats gibt Google Cloud niemals den Inhalt eines privaten Schlüssels zurück. Der private Schlüssel wird sicher gespeichert und kann nicht über die Google Cloud Console, das gcloud-Befehlszeilentool oder die API abgerufen werden.
Sie können globale SSL-Zertifikate nur über die Google Cloud Console auflisten und beschreiben. Verwenden Sie für regionale SSL-Zertifikate die entsprechenden gcloud-Befehle.

SSL-Zertifikate löschen

Bevor Sie ein SSL-Zertifikat löschen können, müssen Sie jeden Zielproxy aktualisieren, der auf das Zertifikat verweist. Führen Sie für jeden Zielproxy den entsprechenden gcloud update-Befehl aus, um die SSL_CERTIFICATE_LIST des Zielproxys so zu aktualisieren, dass sie das zu löschende SSL-Zertifikat nicht mehr enthält. Jeder SSL-Zielproxy oder HTTPS-Zielproxy muss auf mindestens ein SSL-Zertifikat verweisen.

Hinweis: Informationen zur Abfolge der Ereignisse, die Sie beim Ersetzen eines SSL-Zertifikats einhalten müssen, finden Sie unter SSL-Zertifikat vor Ablaufen ersetzen oder verlängern.

Nachdem Sie den Zielproxy aktualisiert haben, können Sie das SSL-Zertifikat löschen.

Console

Sie können globale SSL-Zertifikate auf dem Tab Klassische Zertifikate der Seite Zertifikatmanager löschen.

1. Rufen Sie in der Google Cloud Console den Tab „Klassische Zertifikate” auf.
   Zu den Klassischen Zertifikaten
2. Wählen Sie das SSL-Zertifikat aus, das Sie löschen möchten.
3. Klicken Sie auf Löschen.
4. Klicken Sie zur Bestätigung noch einmal auf Löschen.

gcloud

Verwenden Sie zum Löschen eines globalen SSL-Zertifikats den Befehl gcloud compute ssl-certificates delete mit dem Flag --global:

gcloud compute ssl-certificates delete CERTIFICATE_NAME \
    --global

Verwenden Sie zum Löschen eines regionalen SSL-Zertifikats den Befehl gcloud compute ssl-certificates delete mit dem Flag --region:

gcloud compute ssl-certificates delete CERTIFICATE_NAME \
    --region=REGION

Dabei gilt:

• CERTIFICATE_NAME: Der Name des SSL-Zertifikats.
• REGION: Eine Google Cloud-Region.

SSL-Zertifikat vor Ablauf ersetzen oder verlängern

So ersetzen, verlängern oder rotieren Sie ein SSL-Zertifikat:

1. Führen Sie den Befehl gcloud compute ssl-certificates describe für das aktuelle Zertifikat aus, um zu prüfen, ob es abläuft.

2. Erstellen Sie eine neue SSL-Zertifikatsressource. Das neue SSL-Zertifikat muss innerhalb des Projekts einen eindeutigen Namen haben.

3. Aktualisieren Sie den Zielproxy, um das alte SSL-Zertifikat zu trennen und das neue hinzuzufügen. Achten Sie darauf, dass alle anderen vorhandenen SSL-Zertifikate enthalten sind, die Sie behalten möchten.

   Um Ausfallzeiten zu vermeiden, führen Sie einen einzelnen gcloud-Befehl mit dem Flag --ssl-certificates aus. Beispiel:

   Für globale externe Application Load Balancer:

   Führen Sie den Befehl gcloud compute target-https-proxies update mit dem Flag --global aus.

   gcloud compute target-https-proxies update TARGET_PROXY_NAME \
      --global \
      --ssl-certificates=new-ssl-cert,other-certificates \
      --global-ssl-certificates
   

   Für regionale externe Application Load Balancer und interne Application Load Balancer:

   Führen Sie den Befehl gcloud compute target-https-proxies update mit dem Flag --region aus.

   gcloud compute target-https-proxies update TARGET_PROXY_NAME \
      --region REGION \
      --ssl-certificates=new-ssl-cert,other-certificates \
      --global-ssl-certificates
   

   Für externe Proxy-Network Load Balancer:

   Führen Sie den Befehl gcloud compute target-ssl-proxies update mit dem Flag --backend-service aus.

   gcloud compute target-ssl-proxies update TARGET_PROXY_NAME \
      --ssl-certificates=new-ssl-cert,other-certificates
   

4. Prüfen Sie mit dem folgenden OpenSSL-Befehl, ob der Load-Balancer das Ersatzzertifikat bereitstellt:

   echo | openssl s_client -showcerts -connect IP_ADDRESS:443 -verify 99 -verify_return_error
   

   Hinweis: Wenn mehrere Zertifikate mit dem vom Client angegebenen SNI-Hostnamen übereinstimmen, wählt der Load-Balancer möglicherweise ein anderes Zertifikat als das primäre aus (das erste in der Liste). Weitere Informationen finden Sie unter Mehrere SSL-Zertifikate.

5. Warten Sie 15 Minuten, bis der Ersetzungsvorgang an alle Google Front Ends (GFEs) übertragen wurde.

6. (Optional) Löschen Sie das alte SSL-Zertifikat.

SSL-Zertifikate regelmäßig rotieren

Diese Beispiellösung prüft regelmäßig den Status von Zertifikaten, die mit Google Cloud-Load-Balancern verwendet werden, und rotiert Zertifikate, wenn sie einen bestimmten Prozentsatz ihrer Lebensdauer erreichen. Das Tool verwendet Zertifizierungsstellen, die mit dem Certificate Authority Service konfiguriert wurden.

Diese Lösung funktioniert mit den folgenden Load-Balancern:

• Globalen externen Application Load Balancern
• Klassischer Application Load Balancer
• Regionaler externer Application Load Balancer
• Interner Application Load Balancer
• Externer Proxy-Network Load Balancer mit SSL-Proxy

Wichtig: Diese Lösung ist kein offizielles Produkt und wird von Google nicht unterstützt. Sie wird nur als Beispielreferenz bereitgestellt.

Nächste Schritte

• Fehlerbehebung bei SSL-Zertifikaten