Zertifikatsvorlage erstellen

Auf dieser Seite werden die Attribute einer Zertifikatsvorlage und das Erstellen einer Zertifikatsvorlage erläutert.

Übersicht über Zertifikatsvorlagen

Certificate Authority Service bietet wiederverwendbare und parametrisierte Vorlagen, die Sie für gängige Szenarien der Zertifikatsausstellung verwenden können. Eine Zertifikatsvorlage stellt ein relativ statisches und klar definiertes Schema für die Zertifikatsausstellung innerhalb einer Organisation dar. Die Ressource CertificateTemplate enthält Folgendes.

1. Ein CEL-Ausdruck (Common Expression Language), der in allen Zertifikatsanfragen, die die Vorlage verwenden, anhand des angeforderten Subjekts und der SANs ausgewertet wird. Weitere Informationen zur Verwendung von CEL finden Sie unter CEL verwenden.
2. Eine Zulassungsliste mit der Angabe, ob der Subjekt oder alternativer Antragstellername aus der Endnutzeranfrage in das ausgestellte Zertifikat kopiert werden kann.
3. Eine optionale Zulassungsliste, die angibt, welche X.509-Erweiterungen gegebenenfalls aus der Endnutzeranfrage in das ausgestellte Zertifikat kopiert werden können.
4. Ein optionaler Satz von X.509-Erweiterungswerten, die allen ausgestellten Zertifikaten hinzugefügt werden, die die Vorlage verwenden.

Aus einer Zertifikatsvorlage kann im Prinzip ein vollwertiges vertikales Framework für die Ausstellung von Zertifikaten werden. Weitere Informationen finden Sie in der vollständigen Nachrichtendefinition von CertificateTemplate.

Vordefinierte Werte in einer Zertifikatsvorlage

Die vordefinierten Werte in einer Zertifikatsvorlage werden allen Zertifikaten hinzugefügt, die die Zertifikatsvorlage verwenden. Sie ermöglichen das Erstellen gängiger Szenarien der Zertifikatsausstellung wie mTLS oder Codesignatur. Die Werte umfassen Folgendes:

• Schlüsselverwendungen: Gibt die Basisschlüsselverwendung für ein Zertifikat gemäß RFC 5280-Abschnitt 4.2.1.12 an.
• Erweiterte Schlüsselverwendungen: Gibt die erweiterte Schlüsselnutzung für ein Zertifikat gemäß RFC 5280-Abschnitt 4.2.1.3 an.
• Wenn das Zertifikat eine Zertifizierungsstelle ist: Gibt an, ob das Zertifikat zusätzliche Zertifikate ausstellen kann oder ob es sich um ein Endentitätszertifikat handelt.
• Maximale Ausstellerpfadlänge: Bei einer Zertifizierungsstelle gibt der Wert die maximale Anzahl von Zertifizierungsstellen an, die mit diesem CA-Zertifikat verkettet werden können. Wenn die maximale Ausstellerpfadlänge auf 0 festgelegt ist, kann die Zertifizierungsstelle nur Zertifikate der Endentität ausstellen. Wenn sie auf 1 gesetzt ist, kann die Kette unter diesem CA-Zertifikat nur eine untergeordnete Zertifizierungsstelle enthalten. Wenn ein Wert nicht deklariert wird, ist die Anzahl der untergeordneten Zertifizierungsstellen in der Kette unterhalb dieser Zertifizierungsstelle unbegrenzt.
• AIA-OCSP-Server: Bezieht sich auf die OCSP-Server in der AIA-Erweiterung (Authority Information Access) eines Zertifikats, wie in RFC 5280, Abschnitt 4.2.2.1 beschrieben.
• Zusätzliche X.509-Erweiterungen: Beschreibt benutzerdefinierte X.509-Erweiterungen.

Im folgenden Codebeispiel werden alle vordefinierten Felder einer Zertifikatsvorlage erwähnt:

keyUsage:
  baseKeyUsage:
    digitalSignature: true
    keyEncipherment: true
    contentCommitment: false
    dataEncipherment: false
    keyAgreement: false
    certSign: false
    crlSign: false
    encipherOnly: false
    decipherOnly: false
  extendedKeyUsage:
    serverAuth: true
    clientAuth: false
    codeSigning: false
    emailProtection: false
    timeStamping: false
    ocspSigning: false
caOptions:
  isCa: true
  maxIssuerPathLength: 1
policyIds:
- objectIdPath:
  - 1
  - 2
  - 3
additionalExtensions:
- objectId:
    objectIdPath:
    - 1
    - 2
    - 3
  critical: false
  value: "base64 encoded extension value"

Werte, die nicht in der YAML-Datei angegeben sind, werden entweder weggelassen oder standardmäßig auf false gesetzt.

Die folgenden Erweiterungen werden weggelassen, wenn kein Wert angegeben ist:

• keyUsage
• policyIds
• additionalExtensions
• Feld „maxIssuerPathLength“ in der Erweiterung „caOptions“

Die folgenden Erweiterungen werden standardmäßig auf false gesetzt, wenn kein Wert angegeben ist:

• Feld „isCa“ in der Erweiterung „caOptions“

Zertifikatsvorlage erstellen

Verwenden Sie den folgenden gcloud-Befehl, um eine Zertifikatsvorlage zu erstellen:

gcloud

gcloud privateca templates create TEMPLATE_ID \
  --copy-subject \
  --copy-sans \
  --identity-cel-expression <expr> \
  --predefined-values-file FILE_PATH \
  --copy-all-requested-extensions \
  --copy-extensions-by-oid <1.2.3.4,5.6.7.8> \
  --copy-known-extensions <ext1,ext2>

Ersetzen Sie Folgendes:

• TEMPLATE_ID: die eindeutige Kennung der Zertifikatsvorlage.
• FILE_PATH: die YAML-Datei, die die X.509-Werte beschreibt, die von der Zertifikatsvorlage festgelegt werden.

Mit dem Flag --copy-sans kann die Erweiterung „Subject Alternative Name“ (SAN) aus der Zertifikatsanfrage in das signierte Zertifikat kopiert werden. Alternativ können Sie --no-copy-sans angeben, um alle vom Aufrufer angegebenen SANs aus der Zertifikatsanfrage zu entfernen.

Mit dem Flag --copy-subject kann der Subjekt aus der Zertifikatsanfrage in das signierte Zertifikat kopiert werden. Alternativ können Sie --no-copy-subject angeben, um alle vom Aufrufer angegebenen Themen aus der Zertifikatsanfrage zu entfernen.

Hinweis: Wenn eine Vorlage mit Identitätsreflexion verwendet werden muss, geben Sie die Flags --no-copy-subject und --no-copy-sans zusammen an. Weitere Informationen zur Identitätsreflexion findest du unter Identitätsreflexion.

Das Flag --identity-cel-expression verwendet einen CEL-Ausdruck, der vor der Ausstellung mit dem Subject und Subject Alternative Name des Zertifikats verglichen wird, und gibt einen booleschen Wert zurück, der angibt, ob die Anfrage zulässig ist. Informationen zur Verwendung eines CEL-Ausdrucks (Common Expression Language) für eine Zertifikatsvorlage finden Sie unter CEL für Zertifikatsvorlagen verwenden.

Das Flag --predefined-values-file gibt den Pfad zu einer YAML-Datei an, die alle vordefinierten X.509-Werte beschreibt, die durch diese Vorlage festgelegt werden. Die bereitgestellten Erweiterungen werden in alle Zertifikatsanfragen kopiert, für die diese Vorlage verwendet wird. Sie haben Vorrang vor allen zulässigen Erweiterungen in der Zertifikatsanfrage. Wenn Sie einen Teil der vordefinierten X.509-Werte aktualisieren, ersetzt das Update den gesamten Satz vordefinierter X.509-Werte.

Wenn das Flag --copy-all-requested-extensions gesetzt ist, werden alle in der Zertifikatsanfrage angegebenen Erweiterungen in das signierte Zertifikat kopiert. Alternativ können Sie mit dem Flag --copy-extensions-by-oid bestimmte OIDs aus der Zertifikatsanfrage in das signierte Zertifikat kopieren. Mit dem Flag --copy-known-extensions lassen sich Erweiterungen aus der Zertifikatsanfrage in das signierte Zertifikat kopieren. Hier muss entweder base-key-usage, extended-key-usage, ca-options, policy-ids oder aia-ocsp-servers angegeben werden.

Hinweis: Das Tag --copy-all-requested-extensions schließt sich gegenseitig aus den Flags --copy-known-extensions und --copy-extensions-by-oid.

Entfernen Sie das Flag --copy-all-requested-extensions, um alle X.509-Erweiterungen in der Zertifikatsanfrage zu ignorieren und die in dieser Vorlage definierten vordefinierten Werte beizubehalten.

Hinweis: Wenn Sie Ressourcen wie CA-Pools, Zertifizierungsstellen und Zertifikatsvorlagen löschen, können Sie keine neue Ressource dieses Typs mit demselben Namen im selben Projekt und Standort erstellen.

Zertifikatsvorlage für häufige Szenarien erstellen

Dieser Abschnitt enthält gcloud-Befehle zum Erstellen einer Zertifikatsvorlage für häufige Anwendungsfälle.

TLS-Zertifikate von DNS-Servern für alle Domains

Folgen Sie dieser Anleitung, um eine Zertifikatsvorlage zum Ausstellen von Server-TLS-Zertifikaten zu erstellen, die alle Domains zulassen:

1. Erstellen Sie eine Datei mit dem Namen leaf_server_tls_values.yaml und fügen Sie dieser die folgende TLS-Konfiguration des Endentitätsservers hinzu:

   leaf_server_tls_values.yaml

   keyUsage:
     baseKeyUsage:
       digitalSignature: true
       keyEncipherment: true
     extendedKeyUsage:
       serverAuth: true
   caOptions:
     isCa: false
   

2. Führen Sie den folgenden gcloud-Befehl aus, um nur Zertifikate mit SANs vom Typ DNS zuzulassen:

   gcloud

   gcloud privateca templates create server-tls \
     --predefined-values-file leaf_server_tls_values.yaml \
     --copy-sans --no-copy-subject \
     --identity-cel-expression "subject_alt_names.all(san, san.type == DNS)"
   

   Weitere Informationen zum Befehl gcloud privateca templates create finden Sie unter gcloud privateca Vorlagen create.

TLS-Zertifikate von DNS-Servern mit ausschließlich Testdomains

Verwenden Sie den folgenden gcloud-Befehl, um eine Zertifikatsvorlage zum Ausstellen von Server-TLS-Zertifikaten mit DNS-SANs zu erstellen, die auf Testdomains beschränkt sind:

gcloud

gcloud privateca templates create server-tls \
  --predefined-values-file leaf_server_tls_values.yaml \
  --copy-sans --no-copy-subject \
  --identity-cel-expression "subject_alt_names.all(san, san.type == DNS && san.value.endsWith('.test.example.com'))"

Der Inhalt der Datei leaf_server_tls_values.yaml muss mit dem des vorherigen Beispiels übereinstimmen.

Weitere Informationen zur Verwendung von CEL-Ausdrücken, damit DNS-Namen mit einem bestimmten String beginnen oder enden, finden Sie unter CEL-Beispielausdrücke.

Identitätszertifikate von Arbeitslasten

Folgen Sie dieser Anleitung, um eine Zertifikatsvorlage zum Ausstellen von gegenseitigen TLS-Zertifikaten (mTLS) zu erstellen:

1. Erstellen Sie eine Datei mit dem Namen leaf_mtls_values.yaml und fügen Sie dieser die folgende gegenseitige TLS-Konfiguration der Endentität hinzu.

   leaf_mtls_values.yaml

   keyUsage:
     baseKeyUsage:
       digitalSignature: true
       keyEncipherment: true
     extendedKeyUsage:
       serverAuth: true
       clientAuth: true
   caOptions:
     isCa: false
   

2. Verwenden Sie den folgenden gcloud-Befehl, um nur Zertifikate mit URI-SANs vom Typ SPIFFE zuzulassen:

   gcloud

   gcloud privateca templates create workload-spiffe \
     --predefined-values-file leaf_mtls_values.yaml \
     --copy-sans --no-copy-subject \
     --identity-cel-expression "subject_alt_names.all(san, san.type == URI && san.value.startsWith('spiffe://'))"
   

   Weitere Informationen zum Befehl gcloud privateca templates create finden Sie unter gcloud privateca Vorlagen create.

Weitere Informationen zur Verwendung von CEL-Ausdrücken, damit DNS-Namen mit einem bestimmten String beginnen oder enden, finden Sie unter CEL-Beispielausdrücke.

Zugriff auf die Zertifikatsvorlage gewähren

Sie können eine Zertifikatsvorlage verwenden, wenn Sie die Rolle „Nutzer von CA Service-Zertifikatvorlagen (roles/privateca.templateUser)“ haben. Wir empfehlen, dass die Autoren einer Zertifikatvorlage den Mitgliedern in der Organisation, die diese Zertifikatsvorlage möglicherweise verwenden, die Rolle „Nutzer von CA Service-Zertifikatvorlagen“.

Um allen Nutzern in der Domain example.com die Rolle „CA Service Certificate Template User“ (roles/privateca.templateUser) zuzuweisen, verwenden Sie den folgenden gcloud-Befehl:

gcloud

gcloud privateca templates add-iam-policy-binding TEMPLATE_ID \
  --member "domain:example.com" \
  --role "roles/privateca.templateUser"

Ersetzen Sie Folgendes:

• TEMPLATE_ID: die eindeutige Kennung der Zertifikatsvorlage.

Weitere Informationen zum Befehl gcloud privateca templates add-iam-policy-binding finden Sie unter gcloud privateca Vorlagen add-iam-policy-binding.

Weitere Informationen zu IAM-Rollen für CA Service und die zugehörigen Berechtigungen finden Sie unter Zugriffssteuerung mit IAM.

Nächste Schritte

• Weitere Informationen zur Common Expression Language.
• Weitere Informationen zur Verwendung der Common Expression Language
• Weitere Informationen zu Zertifikatsprofilen