Untergeordnete Zertifizierungsstelle erstellen

Auf dieser Seite wird beschrieben, wie Sie eine untergeordnete Zertifizierungsstelle (Sub-CA) erstellen.

Untergeordnete Zertifizierungsstellen sind für die Ausstellung von Zertifikaten direkt an Endentitäten wie Nutzer, Computer und Geräte verantwortlich. Sie werden kryptografisch von einer übergeordneten Zertifizierungsstelle signiert, oft der Stammzertifizierungsstelle. Systeme, die der Root-CA vertrauen, vertrauen automatisch den untergeordneten CAs und den von ihnen ausgestellten Zertifikaten.

Der Unterzeichner des CA-Zertifikats kann entweder eine andere in CA Service erstellte CA, z. B. eine Stamm-CA, oder eine externe CA sein. Bei externen CAs generiert CA Service eine Anfrage für die Signierung des Zertifikats (Certificate Signing Request = CSR), die von der externen CA signiert werden muss.

Hinweise

Bitten Sie Ihren IAM-Administrator der Organisation, Ihnen die Rolle „Certificate Authority Service Admin“ (certificate-authority-service-admin) zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Erstellen einer untergeordneten Zertifizierungsstelle benötigen. Weitere Informationen zu Rollen finden Sie unter Rollendefinitionen.

kubeconfig-Datei abrufen

Damit Sie Befehle für den Management API-Server ausführen können, benötigen Sie die folgenden Ressourcen:

Verwaltete untergeordnete CA erstellen

Bei einer verwalteten untergeordneten CA ist der Unterzeichner des CA-Zertifikats eine andere CA (Stamm-CA), die in CA Service erstellt wurde.

Wenn Sie eine verwaltete untergeordnete Zertifizierungsstelle erstellen möchten, wenden Sie eine benutzerdefinierte Ressource auf Ihre Distributed Cloud Appliance-Instanz an.

  1. Erstellen Sie eine CertificateAuthority-Ressource und speichern Sie sie als YAML-Datei mit dem Namen subca.yaml:

    apiVersion: pki.security.gdc.goog/v1
    kind: CertificateAuthority
    metadata:
      Name: SUB_CA_NAME
      namespace: USER_PROJECT_NAMESPACE
    spec:
      caProfile:
        commonName: COMMON_NAME
        duration: DURATION
        renewBefore: RENEW_BEFORE
        organizations:
        - ORGANIZATIONS
        organizationalUnits:
        - ORGANIZATIONAL_UNITS
        countries:
        - COUNTRIES
        localities:
        - LOCALITIES
        provinces:
        - PROVINCES
        streetAddresses:
        - STREET_ADDRESSES
        postalCodes:
        - POSTAL_CODES
      caCertificate:
        managedSubCA:
          certificateAuthorityRef:
            name: ROOT_CA_NAME
            namespace: USER_PROJECT_NAMESPACE
      certificateProfile:
        keyUsage:
          - digitalSignature
          - keyCertSign
          - crlSign
        extendedKeyUsage:
          - EXTENDED_KEY_USAGE
      secretConfig:
        secretName: SECRET_NAME
        privateKeyConfig:
          algorithm: KEY_ALGORITHM
          size: KEY_SIZE
      acme:
        enabled: ACME_ENABLED
    

    Ersetzen Sie die folgenden Variablen:

    Variable Beschreibung
    SUB_CA_NAME Der Name der untergeordneten CA.
    USER_PROJECT_NAMESPACE Der Name des Namespace, in dem sich das Nutzerprojekt befindet.
    COMMON_NAME Der allgemeine Name des CA-Zertifikats.
    DURATION Die angeforderte Lebensdauer des CA-Zertifikats.
    ROOT_CA_NAME Der Name der Stammzertifizierungsstelle.
    SECRET_NAME Der Name des Kubernetes-Secrets, das den privaten Schlüssel und das signierte CA-Zertifikat enthält.

    Die folgenden Variablen sind optionale Werte:

    Variable Beschreibung
    RENEW_BEFORE Die Rotationszeit, bevor das CA-Zertifikat abläuft.
    ORGANIZATIONS Organisationen, die im Zertifikat verwendet werden sollen.
    ORGANIZATIONAL_UNITS Organisationseinheiten, die im Zertifikat verwendet werden sollen.
    COUNTRIES Länder, die im Zertifikat verwendet werden sollen.
    LOCALITIES Städte, die im Zertifikat verwendet werden sollen.
    PROVINCES Bundesland oder Provinz, die im Zertifikat verwendet werden sollen.
    STREET_ADDRESSES Straßenadressen, die auf dem Zertifikat verwendet werden sollen.
    POSTAL_CODES Postleitzahlen, die auf dem Zertifikat verwendet werden sollen.
    EXTENDED_KEY_USAGE Die erweiterte Schlüsselverwendung für das Zertifikat. Wenn ein Wert angegeben wird, sind die zulässigen Werte serverAuth und clientAuth.
    KEY_ALGORITHYM Der für dieses Zertifikat verwendete Algorithmus für den privaten Schlüssel. Zulässige Werte sind RSA, Ed25519 oder ECDSA. Wenn die Größe nicht angegeben ist, wird standardmäßig 256 für ECDSA und 2048 für RSA verwendet. Die Schlüsselgröße wird für Ed25519 ignoriert.
    KEY_SIZE Die Größe des privaten Schlüssels für dieses Zertifikat in Bit hängt vom Algorithmus ab. RSA unterstützt 2.048, 3.072, 4.096 oder 8.192 Bit (Standard: 2.048). ECDSA unterstützt 256, 384 oder 521 (Standard: 256). Bei Ed25519 wird die Größe ignoriert.
    ACME_ENABLED Wenn auf true festgelegt, wird die CA im ACME-Modus ausgeführt und gibt die ACME-Server-URL aus. Anschließend können Sie den ACME-Client und das ACME-Protokoll verwenden, um Zertifikate zu verwalten.
  2. Wenden Sie die benutzerdefinierte Ressource auf Ihre Distributed Cloud-Instanz an:

    kubectl apply -f subca.yaml --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG
    

    Ersetzen Sie MANAGEMENT_API_SERVER_KUBECONFIG durch den Pfad zur kubeconfig-Datei des Management API-Servers.

  3. Prüfen Sie, ob die untergeordnete CA bereit ist. Es dauert etwa 40 Minuten, bis die Zertifizierungsstelle bereit ist:

    kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG -n USER_PROJECT_NAMESPACE get certificateauthority.pki.security.gdc.goog/SUB_CA_NAME -ojson | jq -r ' 
    .status.conditions[] | select( .type as $id | "Ready" | index($id))'
    

    Die Ausgabe sieht dann ungefähr so aus:

    {
      "lastTransitionTime": "2025-01-24T17:09:29Z",
      "message": "CA reconciled",
      "observedGeneration": 2,
      "reason": "Ready",
      "status": "True",
      "type": "Ready"
    }
    

Untergeordnete CA aus einer externen CA erstellen

Mit dieser untergeordneten CA können Blattzertifikate mit externen oder von Nutzern verwalteten CAs signiert werden. Es wird eine CSR für Nutzer zum Signieren generiert.

  1. Erstellen Sie eine CertificateAuthority-Ressource und speichern Sie sie als YAML-Datei mit dem Namen subca-external.yaml:

    apiVersion: pki.security.gdc.goog/v1
    kind: CertificateAuthority
    metadata:
      Name: SUB_CA_NAME
      namespace: USER_PROJECT_NAMESPACE
    spec:
      caProfile:
        commonName: COMMON_NAME
        duration: DURATION
        renewBefore: RENEW_BEFORE
        organizations:
        - ORGANIZATION
        organizationalUnits:
        - ORGANIZATIONAL_UNITS
        countries:
        - COUNTRIES
        localities:
        - LOCALITIES
        provinces:
        - PROVINCES
        streetAddresses:
        - STREET_ADDRESSES
        postalCodes:
        - POSTAL_CODES
      caCertificate:
        externalCA: {}
      certificateProfile:
        keyUsage:
          - digitalSignature
          - keyCertSign
          - crlSign
        extendedKeyUsage:
          - EXTENDED_KEY_USAGE
      secretConfig:
        secretName: SECRET_NAME
        privateKeyConfig:
          algorithm: KEY_ALGORITHM
          size: KEY_SIZE
      acme:
        enabled: ACME_ENABLED
    

    Ersetzen Sie die folgenden Variablen:

    Variable Beschreibung
    SUB_CA_NAME Der Name der untergeordneten CA.
    USER_PROJECT_NAMESPACE Die Projekt-ID des Projekts, in das Sie das Image importieren möchten.
    COMMON_NAME Der allgemeine Name des CA-Zertifikats.
    DURATION Die angeforderte Lebensdauer des CA-Zertifikats
    SECRET_NAME Der Name des Kubernetes-Secrets, das den privaten Schlüssel und das signierte CA-Zertifikat enthält.

    Die folgenden Variablen sind optionale Werte:

    Variable Beschreibung
    RENEW_BEFORE Die Rotationszeit, bevor das CA-Zertifikat abläuft.
    ORGANIZATION Die Organisation, die im Zertifikat verwendet werden soll.
    ORGANIZATIONAL_UNITS Organisationseinheiten, die im Zertifikat verwendet werden sollen.
    COUNTRIES Länder, die im Zertifikat verwendet werden sollen.
    LOCALITIES Städte, die im Zertifikat verwendet werden sollen.
    PROVINCES Bundesland oder Provinz, die im Zertifikat verwendet werden sollen.
    STREET_ADDRESSES Straßenadressen, die auf dem Zertifikat verwendet werden sollen.
    POSTAL_CODES Postleitzahlen, die auf dem Zertifikat verwendet werden sollen.
    EXTENDED_KEY_USAGE Die erweiterte Schlüsselverwendung für das Zertifikat. Wenn ein Wert angegeben wird, sind die zulässigen Werte serverAuth und clientAuth.
    KEY_ALGORITHYM Der für dieses Zertifikat verwendete Algorithmus für den privaten Schlüssel. Zulässige Werte sind RSA, Ed25519 oder ECDSA. Wenn die Größe nicht angegeben ist, wird standardmäßig 256 für ECDSA und 2048 für RSA verwendet. Die Schlüsselgröße wird für Ed25519 ignoriert.
    KEY_SIZE Die Größe des privaten Schlüssels für dieses Zertifikat in Bit hängt vom Algorithmus ab. RSA kann 2048, 3072, 4096 oder 8192 sein (Standard: 2048). ECDSA kann 256, 384 oder 521 sein (Standard: 256). Ed25519 ignoriert die Größe.
    ACME_ENABLED Wenn auf true festgelegt, wird die CA im ACME-Modus ausgeführt und gibt die ACME-Server-URL aus. Anschließend können Sie den ACME-Client und das ACME-Protokoll verwenden, um Zertifikate zu verwalten.
  2. Wenden Sie die benutzerdefinierte Ressource auf Ihre Distributed Cloud-Instanz an:

    kubectl apply -f subca-external.yaml --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG
    
  3. Eine CSR für die untergeordnete CA wird auf dem GDC Management API-Server generiert. Sie müssen die CSR herunterladen und signieren. Nach der Unterzeichnung können Sie das signierte Zertifikat auf den GDC Management API-Server hochladen.

  4. Erstellen Sie die Zertifikatsignierungsanfragen (Certificate Signing Requests, CSRs) in Ihrer Distributed Cloud-Umgebung:

    kubectl get certificateauthorities SUB_CA_NAME -n USER_PROJECT_NAMESPACE -ojson | jq -j '"echo ", .status.externalCA.csr, " | base64 -d > ","sub_ca.csr\n"' | bash
    

    Mit dem Befehl wird im aktuellen Verzeichnis eine CSR-Datei mit dem Namen sub_ca.csr generiert. Diese Datei enthält eine CSR für ein X.509-Zertifizierungsstellenzertifikat.

  5. Verwenden Sie die Stammzertifizierungsstelle des Kunden, um signierte CA-Zertifikate für die Datei sub_ca.csr anzufordern.

  6. Für eine genehmigte Anfrage für die Signierung des Zertifikats müssen Sie ein CA-Zertifikat abrufen, das von der Stammzertifizierungsstelle des Kunden signiert wurde. Speichern Sie das Zertifikat in der Datei sub_ca.crt im aktuellen Verzeichnis.

  7. Falls zutreffend, holen Sie das Root-CA-Zertifikat des Kunden ein und speichern Sie es in der Datei ca.crt im aktuellen Verzeichnis.

  8. Prüfen Sie die Erweiterungen für alternative Antragstellernamen (Subject Alternative Name, SAN) im Zertifikat:

    openssl x509 -text -noout -in sub_ca.crt | grep -A 1 "Subject Alternative Name"
    

    Wenn das CA-Zertifikat einen Common Name (CN) anstelle eines SAN hat, prüfen Sie den CN im Zertifikat:

    openssl x509 -text -noout -in sub_ca.crt | grep -A 1 "Subject: CN"
    
  9. Generieren Sie die spec, um die Ressource CertificateAuthority zu patchen:

    echo "spec:
      caCertificate:
        externalCA:
          signedCertificate:
            certificate: $(base64 -w0 SUB_CA_NAME.crt)
            ca: $(base64 -w0 ca.crt)" > patch.txt
    

    Der Inhalt der Datei patch.txt sieht in etwa so aus:

    spec:
      caCertificate:
        externalCA:
          signedCertificate:
            certificate: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURSekNDQ…
            ca: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURRVENDQ…
    
  10. Bearbeiten Sie das Feld spec der Ressource CertificateAuthority:

    kubectl patch certificateauthority SUB_CA_NAME -n USER_PROJECT_NAMESPACE--patch-file patch.txt --type='merge'
    
  11. Prüfen Sie, ob die eigene untergeordnete Zertifizierungsstelle (BYO) bereit ist. Normalerweise dauert es etwa 40 Minuten, bis die CA bereit ist:

    kubectl -n USER_PROJECT_NAMESPACE get certificateauthority.pki.security.gdc.goog/SUB_CA_NAME -ojson | jq -r ' .status.conditions[] | select( .type as $id | "Ready" | index($id))'
    

    Die Ausgabe sieht dann ungefähr so aus:

    {
      "lastTransitionTime": "2024-04-30T22:10:50Z",
      "message": "Certificate authority is ready for use",
      "observedGeneration": 3,
      "reason": "Ready",
      "status": "True",
      "type": "Ready"
    }
    
  12. Prüfen Sie das Ablaufdatum der signierten CA-Zertifikate:

    kubectl -n USER_PROJECT_NAMESPACE get secret SECRET_NAME -ojson | jq -j '"echo ", .metadata.name, " $(echo ", .data["tls.crt"], "| base64 -d | openssl x509 -enddate -noout)\n"' | bash
    

Zertifizierungsstellen auflisten

So listen Sie alle Certificate Authority Service-Ressourcen in Ihrer Air-Gap-Instanz von Distributed Cloud auf:

Verwenden Sie den Parameter certificateauthorities, um alle CertificateAuthority-Ressourcen aufzulisten:

   kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG -n USER_PROJECT_NAMESPACE get certificateauthorities

Die Ausgabe sieht dann ungefähr so aus:

   NAMESPACE    NAME              READY   REASON   AGE
   foo          root-ca           True    Ready    7h24m
   foo          sub-ca            True    Ready    7h24m