Zertifikatsvorlage erstellen

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

Zertifikatsvorlagen – Übersicht

Der Certificate Authority Service bietet wiederverwendbare und parametrisierte Vorlagen, die Sie für gängige Szenarien zur Zertifikatausstellung 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, in der angegeben ist, welche X.509-Erweiterungen (falls vorhanden) 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 zu einem vollwertigen vertikalen 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. Sie ermöglichen die Erstellung gängiger Szenarien für die Zertifikatsausstellung, z. B. mTLS oder Codesignatur. 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.
  • Ob es sich bei dem Zertifikat um eine Zertifizierungsstelle handelt: Gibt an, ob mit dem Zertifikat weitere Zertifikate ausgestellt werden können oder ob es sich um ein Zertifikat für Endentitäten 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 kein Wert angegeben wird, ist die Anzahl der untergeordneten Zertifizierungsstellen in der Kette unter 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 Zertifikatvorlage 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 von der Zertifikatsvorlage festgelegten X.509-Werte beschreibt.

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

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

Das Flag --identity-cel-expression nimmt einen CEL-Ausdruck an, der vor der Ausstellung mit dem Inhaber und dem alternativen Inhabernamen des Zertifikats verglichen wird. Er gibt einen booleschen Wert zurück, der angibt, ob die Anfrage zugelassen werden soll. Informationen zur Verwendung eines CEL-Ausdrucks (Common Expression Language) 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, in der alle vordefinierten X.509-Werte beschrieben werden, die mit dieser Vorlage festgelegt wurden. Die angegebenen Erweiterungen werden in alle Zertifikatsanfragen kopiert, die diese Vorlage verwenden. Sie haben Vorrang vor allen 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 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 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.

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.

Zertifikatsvorlage für gängige Szenarien erstellen

In diesem Abschnitt finden Sie gcloud-Befehle zum Erstellen einer Zertifikatvorlage für gängige Anwendungsfälle.

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

So erstellen Sie eine Zertifikatsvorlage für die Ausstellung von Server-TLS-Zertifikaten, die jede Domain zulassen:

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

    leaf_server_tls_values.yaml

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

  2. Wenn Sie nur Zertifikate mit SANs vom Typ DNS zulassen möchten, führen Sie den folgenden gcloud-Befehl aus:

    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 templates 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 des vorherigen Beispiels übereinstimmen.

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

Zertifikate für Workload Identity

So erstellen Sie eine Zertifikatsvorlage zum Ausstellen von Zertifikaten für die gegenseitige TLS-Authentifizierung (mTLS):

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

    leaf_mtls_values.yaml

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

  2. Wenn Sie nur Zertifikate mit SPIFFE-URI-SANs zulassen möchten, verwenden Sie den 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 templates create.

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

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 den Autoren einer Zertifikatsvorlage, den Mitgliedern der Organisation, die diese Zertifikatsvorlage verwenden könnten, die Rolle „Nutzer der CA Service-Zertifikatsvorlage“ zu gewähren.

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 templates add-iam-policy-binding.

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

Nächste Schritte