Zertifikatsvorlage erstellen

Auf dieser Seite werden die Attribute einer Zertifikatvorlage beschrieben und erläutert, wie Sie eine Zertifikatvorlage erstellen.

Zertifikatsvorlagen – Übersicht

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 gut definiertes Schema für die Zertifikatsausstellung innerhalb einer Organisation dar. Die CertificateTemplate-Ressource enthält Folgendes:

1. Ein Common Expression Language (CEL)-Ausdruck, der in allen Zertifikatsanfragen, in denen die Vorlage verwendet wird, anhand des angeforderten Inhabers und der SANs ausgewertet wird. Weitere Informationen zur Verwendung von CEL finden Sie unter CEL verwenden.
2. Eine Zulassungsliste, die angibt, ob der Inhaber oder der alternative Inhabername 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. Optionale X.509-Erweiterungswerte, die allen ausgestellten Zertifikaten hinzugefügt werden, die die Vorlage verwenden.

Eine Zertifikatsvorlage kann im Grunde ein vollständiges vertikales Framework für die Ausstellung von Zertifikaten werden. Weitere Informationen finden Sie in der vollständigen Nachrichtendefinition für CertificateTemplate.

Vordefinierte Werte in einer Zertifikatsvorlage

Die vordefinierten Werte in einer Zertifikatsvorlage werden allen Zertifikaten hinzugefügt, die die Zertifikatsvorlage verwenden. Damit lassen sich gängige Szenarien der Zertifikatsausstellung wie mTLS oder Codesignatur erstellen. Zu den Werten gehören:

• Schlüsselverwendungen: Gibt die Basisschlüsselverwendung für ein Zertifikat gemäß RFC 5280 Abschnitt 4.2.1.12 an.
• Erweiterte Schlüsselverwendung: Gibt die erweiterte Schlüsselverwendung für ein Zertifikat gemäß RFC 5280 Abschnitt 4.2.1.3 an.
• Wenn es sich um eine Zertifizierungsstelle handelt: Gibt an, ob mit dem Zertifikat zusätzliche Zertifikate ausgestellt werden können oder ob es sich um ein Zertifikat der Endentität handelt.
• Max. Ausstellerpfadlänge: Gibt bei einer Zertifizierungsstelle 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 Endentitätszertifikate ausstellen. Wenn der Wert 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: Hier werden benutzerdefinierte X.509-Erweiterungen beschrieben.

Im folgenden Codebeispiel werden alle vordefinierten Felder in einer Zertifikatvorlage 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

Für die folgenden Erweiterungen wird standardmäßig false verwendet, 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 ID der Zertifikatsvorlage.
• FILE_PATH: Die YAML-Datei, in der die von der Zertifikatsvorlage festgelegten X.509-Werte beschrieben werden.

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

Das Flag --copy-subject ermöglicht, dass der Betreff aus der Zertifikatsanfrage in das signierte Zertifikat kopiert wird. Sie können alternativ --no-copy-subject angeben, um alle vom Aufrufer angegebenen Betreffs aus der Zertifikatsanfrage zu löschen.

Hinweis: Wenn Sie sicherstellen möchten, dass 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ätsübernahme finden Sie unter Identitätsübernahme.

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

Das Flag --predefined-values-file gibt den Pfad zu einer YAML-Datei an, die alle von dieser Vorlage festgelegten vordefinierten X.509-Werte beschreibt. Die angegebenen Erweiterungen werden in alle Zertifikatsanfragen kopiert, für die diese Vorlage verwendet wird, und haben Vorrang vor zulässigen Erweiterungen in der Zertifikatsanfrage. Wenn Sie einen Teil der vordefinierten X.509-Werte aktualisieren, wird durch die Aktualisierung der gesamte Satz der vordefinierten X.509-Werte ersetzt.

Wenn das Flag --copy-all-requested-extensions festgelegt 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 können Sie Erweiterungen aus der Zertifikatsanfrage in das signierte Zertifikat kopieren. Es muss sich um einen dieser Algorithmen handeln: base-key-usage, extended-key-usage, ca-options, policy-ids oder aia-ocsp-servers.

Hinweis: Das Tag-Flag --copy-all-requested-extensions schließt die Flags --copy-known-extensions und --copy-extensions-by-oid aus.

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

Hinweis: Wenn Sie Ressourcen wie CA-Pools, Zertifizierungsstellen und Zertifikatsvorlagen erstellen, können Sie davon keine neue Ressource erstellen. mit demselben Namen im selben Projekt und am selben Ort ein.

Zertifikatsvorlage für häufige Szenarien erstellen

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

DNS-Server-TLS-Zertifikate für jede Domain

So erstellen Sie eine Zertifikatsvorlage für ausstellende Server-TLS-Zertifikate, die einer beliebigen Domain verwenden Sie die folgende Anleitung:

1. Erstellen Sie eine Datei mit dem Namen leaf_server_tls_values.yaml und fügen Sie die folgende TLS-Konfiguration für den Endentitätsserver 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 template create.

DNS-Server-TLS-Zertifikate mit nur Testdomains

Verwenden Sie den folgenden gcloud-Befehl, um eine Zertifikatvorlage 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 Inhalt des vorherigen Beispiels übereinstimmen.

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

Zertifikate für Workload Identity

Um eine Zertifikatsvorlage für das Ausstellen von gegenseitigen TLS-Zertifikaten (mTLS) zu erstellen, verwenden Sie die folgende Anleitung:

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

   leaf_mtls_values.yaml

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

2. Wenn Sie nur Zertifikate mit URI-SANs vom Typ SPIFFE zulassen möchten, verwenden Sie die Methode folgenden gcloud-Befehl:

   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 template create.

Weitere Informationen zur Verwendung von CEL-Ausdrücken, mit denen 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 der CA Service-Zertifikatsvorlage“ (roles/privateca.templateUser) haben. Wir empfehlen, dass die Autoren einer Zertifikatsvorlage den Mitgliedern in der Organisation, die diese Zertifikatsvorlage möglicherweise verwenden, die Rolle „Nutzer von CA Service-Zertifikatsvorlagen“ zuweisen.

Wenn Sie allen Nutzern in der Domain example.com die Rolle „Nutzer der CA Service-Zertifikatsvorlage“ (roles/privateca.templateUser) zuweisen möchten, 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 template add-iam-policy-binding.

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

Nächste Schritte

• Weitere Informationen zu Common Expression Language
• Weitere Informationen zur Verwendung der Common Expression Language
• Weitere Informationen zu Zertifikatprofilen