Keyfactor EJBCA-Referenzimplementierung

Übersicht

In diesem Leitfaden wird die Integration von Keyfactor EJBCA Enterprise (als externe Appliance bereitgestellt) als Drittanbieter-Zertifizierungsstelle (CA) für Google Distributed Cloud (GDC) mit Air Gap beschrieben.

Keyfactor EJBCA Enterprise ist eine hochskalierbare, robuste und FIPS-konforme Zertifizierungsstellenplattform, mit der Unternehmen die Public-Key-Infrastruktur (PKI) in heterogenen Umgebungen verwalten können.

GDC mit Air Gap enthält einen integrierten Certificate Authority Service für die automatisierte Schlüssel- und Zertifikatsverwaltung innerhalb der gehosteten Cloud-Grenze. Organisationen, die ihre PKI-Infrastruktur für vorhandene Arbeitslasten außerhalb von GDC auf Keyfactor EJBCA standardisiert haben, bevorzugen jedoch möglicherweise dieselbe konsistente CA-Architektur und dieselben Verwaltungsrichtlinien für Arbeitslasten, die in ihren GDC-Umgebungen mit Air Gap ausgeführt werden.

In diesem Leitfaden wird beschrieben, wie Sie das GDC-Netzwerk, das interne DNS und den Kubernetes-Zertifikatsmanager konfigurieren, um die Verwaltung des Zertifikatslebenszyklus (ACME) zu automatisieren und die programmatische Ausstellung großer Mengen mithilfe eines Registrierungsstellenmusters zu unterstützen.

Annahmen

Bevor Sie mit dieser Anleitung fortfahren, müssen die folgenden Voraussetzungen erfüllt sein:

  • Keyfactor EJBCA wird entweder als Software- oder Hardware-Appliance bereitgestellt und für den Dienst wird eine stabile IP-Adresse konfiguriert.
  • In der EJBCA-Instanz wurden Root-, untergeordnete und Verwaltungs-Zertifizierungsstellen (CAs) erstellt.
  • End Entity-Profile (EE) wurden konfiguriert (z.B. für TLS-Serverzertifikate).
  • Zertifikate für die administrativen CA-Nutzer wurden heruntergeladen.
  • Erforderliche Protokolle (z. B. ACME) sind auf der EJBCA-Instanz aktiviert.
  • In dieser Anleitung werden RSA-Signaturalgorithmen verwendet. Sie können den Signaturalgorithmus entsprechend Ihren spezifischen Anforderungen oder der Konfiguration in Ihrer EJBCA-Instanz ändern.

Architektur

Die Architektur folgt dem Modell der externen Zertifizierungsstelle, bei dem der EJBCA-Server und das zugrunde liegende Hardwaresicherheitsmodul (HSM) extern außerhalb der physischen GDC-Grenzen gehostet werden, aber über das Netzwerk zugänglich sind. Der EJBCA-Server kann extern entweder als Hardware- oder Software-Appliance bereitgestellt werden. Für die in diesem Leitfaden beschriebene Kernintegration ist nur erforderlich, dass der externe EJBCA-Server über eine stabile IP-Adresse erreichbar ist.

Diagramm der Keyfactor EJBCA-Architektur.

Zu den wichtigsten Komponenten dieser Architektur gehören:

  • EJBCA Enterprise Server: Wird extern entweder als Keyfactor-Hardware-Appliance oder als Software-Appliance bereitgestellt, die die Zertifizierungsstellen (Stamm- und untergeordnete Zertifizierungsstellen) enthält und alle Zertifizierungsstellenschlüssel in einem CC EAL4+-zertifizierten HSM generiert.
  • GDC-Standard-Kubernetes-Cluster: Die Compute-Umgebung, in der Kundenarbeitslasten, cert-manager und Integrationsproxys ausgeführt werden.
  • Internes GDC-DNS: Verwaltet lokale private DNS-Zonen (mit dem in den Umgebungsvariablen konfigurierten privaten Domainnamen), die zum Auflösen von ACME-DNS-01-Challenges verwendet werden.
  • GDC-Ausgangs-Gateway: Leitet ausgehenden Traffic von Cluster-Pods an die externe IP-Adresse des EJBCA-Servers weiter.
  • Private Harbor-Registry: Hostet gespiegelte Container-Images (z. B. den EJBCA-cert-manager-Aussteller) für die Bereitstellung mit Air Gap.

Hinweis

Prüfen Sie vor Beginn der Integration, ob Ihre GDC-Umgebung die folgenden Anforderungen erfüllt:

  • Erstellen Sie zuerst ein Projekt, das als Container für alle Ressourcen dient, die in diesem Leitfaden generiert werden.

  • Konfigurieren Sie Umgebungsvariablen, auf die in diesem Leitfaden verwiesen wird. Ändern Sie diese Werte nach Bedarf, um sie an Ihre spezifische Umgebung anzupassen:

    # GDC Environment Configuration
export GDC_ORG="your-org-name"
export GDC_ZONE="your-zone-name"
export GDC_PROJECT_ID="your-project-id"
export GDC_USER_NAME="your-gdc-user-email"
export GDC_CLUSTER_NAME="your-cluster-name"

# EJBCA Server Configuration
export EJBCA_DNS_ZONE="example.internal"
export EJBCA_HOSTNAME="ejbca.${EJBCA_DNS_ZONE}"
export EJBCA_LB_IP="XX.XX.XX.XX" # Stable IP of your EJBCA Server
export EJBCA_CA_NAME="GDC Subordinate CA"
export EJBCA_NAMESPACE="ejbca-ee"
export CERTIFICATE_PROFILE_NAME="GDC TLS SERVER PROFILE"
export END_ENTITY_PROFILE_NAME="GDC TLS SERVER EE PROFILE"

# Harbor Private Registry Configuration
export HARBOR_INSTANCE_URL="your-harbor-url.internal"
export HARBOR_PROJECT="your-harbor-project"
export HARBOR_ROBOT_ACCOUNT="robot$your-robot-name"
export HARBOR_ROBOT_SECRET="your-robot-secret"
export HARBOR_PULL_SECRET_NAME="harbor-secret"

  • Netzwerkhinweis: In diesem Leitfaden wird davon ausgegangen, dass er von einem Bastion-Knoten ausgeführt wird, der Zugriff auf die GDC-APIs mit Air Gap und auf das Internet hat, um die erforderlichen Manifeste und Container-Images herunterzuladen. Wenn Sie dies auf einem Computer ohne Internetzugriff ausführen, müssen Sie diese Assets separat abrufen (z. B. mit docker save, um Images von einem verbundenen Computer zu exportieren, und mit docker load, um sie zu importieren) und sie sicher in Ihre Umgebung hochladen, bevor Sie fortfahren.

kubectl-Aliasse konfigurieren

In diesem Abschnitt erstellen Sie praktische Befehlszeilen-Aliasse für die zonalen Verwaltungs- und globalen APIs von GDC:

  • Erstellen Sie einen Alias für die zonale Verwaltungs-API. Ersetzen Sie dabei MANAGEMENT_API_KUBECONFIG durch den Pfad zur kubeconfig-Datei für die Verwaltungs-API:

    alias km="kubectl --kubeconfig MANAGEMENT_API_KUBECONFIG"

  • Erstellen Sie einen Alias für die globale API. Ersetzen Sie dabei GLOBAL_API_KUBECONFIG durch den Pfad zur kubeconfig-Datei für die globale API:

    alias kg="kubectl --kubeconfig GLOBAL_API_KUBECONFIG"

GDC-Standardcluster erstellen

In diesem Abschnitt stellen Sie einen Kubernetes-Standardcluster in GDC bereit und konfigurieren GDC-Standardcluster-Administratorrollen und lokale Harbor-Container-Registry-Anmeldedaten:

1. Ermitteln Sie die verfügbaren VM-Image-Typen, indem Sie Folgendes ausführen:

```shell
gdcloud compute machine-types list
```

2 Wählen Sie einen geeigneten Maschinentyp für die Worker-Knoten des Clusters aus:

```shell
export MACHINE_TYPE="n3-standard-8-gdc"
```

3 Erstellen Sie mit der zonalen Verwaltungs-API einen Standardcluster mit zwei Worker-Knoten:

```shell
km create -f - <<EOF
apiVersion: cluster.gdc.goog/v1
kind: Cluster
metadata:
  name: ${GDC_CLUSTER_NAME}
  namespace: ${GDC_PROJECT_ID}
spec:
  nodePools:
  - machineTypeName: ${MACHINE_TYPE}
    nodeCount: 2
    name: ${GDC_CLUSTER_NAME}-node-pool
EOF
```

This creates a simple GDC cluster. Cluster creation
can take up to 60 minutes to complete. To check the status, use the
following command:

```shell
km get clusters/${GDC_CLUSTER_NAME} \
  -n ${GDC_PROJECT_ID} \
  --watch
```

After the cluster is ready, the output should show a STATE of `Running`.

4 Rufen Sie die Anmeldedaten des Clusters ab, sobald er bereit ist:

```shell
KUBECONFIG=kubeconfig-${GDC_CLUSTER_NAME}.yaml gdcloud clusters \
  get-credentials ${GDC_CLUSTER_NAME} \
  --standard \
  --project ${GDC_PROJECT_ID} \
  --zone ${GDC_ZONE}
```

5 Weisen Sie Ihrem GDC-Nutzer die GDC-Standardcluster-Administratorrollen zu:

```shell
gdcloud projects add-iam-policy-binding ${GDC_PROJECT_ID} \
  --member="user:${GDC_USER_NAME}" \
  --role=cluster-admin

gdcloud projects add-iam-policy-binding ${GDC_PROJECT_ID} \
  --member="user:${GDC_USER_NAME}" \
  --role=standard-cluster-admin
```

6 Erstellen Sie eine Harbor-Instanz und ein Harbor-Projekt in GDC, um die gespiegelten Container-Images zu hosten:

```shell
gdcloud projects add-iam-policy-binding ${GDC_PROJECT_ID} \
  --member="user:${GDC_USER_NAME}" \
  --role=harbor-instance-admin
```

7 Erstellen Sie ein Harbor-Roboterkonto und notieren Sie sich den Nutzernamen und den Secret Key.

8 Authentifizieren Sie sich bei Ihrer Harbor-Instanz:

```shell
docker --config=./docker-harbor login ${HARBOR_INSTANCE_URL} \
  -u ${HARBOR_ROBOT_ACCOUNT} \
  -p ${HARBOR_ROBOT_SECRET}
```

This saves the robot account credentials to
`./docker-harbor/config.json` for subsequent Secret creation.

Infrastruktur- und Netzwerkkonfiguration

In diesem Abschnitt konfigurieren Sie die zugrunde liegende GDC-Infrastruktur und die Netzwerkeinstellungen. So wird sichergestellt, dass Ihre Kubernetes-Arbeitslasten den externen EJBCA-Host-Domainnamen auflösen und ausgehende API-Aufrufe erfolgreich an die IP-Adresse weiterleiten können.

Privates DNS in GDC mit Air Gap einrichten

Um die Domainauflösung einzurichten, stellen Sie eine private DNS-Zone und einen Datensatz bereit, um den externen EJBCA-Server einem lokalen Domainnamen zuzuordnen. So können Dienste innerhalb von GDC eine Verbindung über einen stabilen Hostnamen anstelle einer unformatierten IP-Adresse herstellen:

  • Weisen Sie Ihrem Nutzer die Rolle „Managed DNS Project Admin“ zu:

    gdcloud projects add-iam-policy-binding ${GDC_PROJECT_ID} \
  --member=user:${GDC_USER_NAME} \
  --role=managed-dns-project-admin

  • Stellen Sie die globale ManagedDNSZone-Ressource bereit:

    kubectl --kubeconfig GLOBAL_API_KUBECONFIG apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ManagedDNSZone
metadata:
  name: private-example-internal
  namespace: ${GDC_PROJECT_ID}
spec:
  dnsName: ${EJBCA_DNS_ZONE}
  visibility: PRIVATE
EOF

  • Stellen Sie die ResourceRecordSet bereit, die auf die IP-Adresse Ihrer EJBCA-Appliance verweist:

    kubectl --kubeconfig GLOBAL_API_KUBECONFIG apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ResourceRecordSet
metadata:
  name: ${EJBCA_HOSTNAME}
  namespace: ${GDC_PROJECT_ID}
spec:
  name: ${EJBCA_HOSTNAME}
  ttlSeconds: 600
  type: A
  rrData:
  - ${EJBCA_LB_IP}
  dnsZone: private-example-internal
EOF

NAT-Gateway für ausgehenden Traffic einrichten

Als Nächstes konfigurieren Sie das ausgehende GDC-Netzwerk, indem Sie ein benutzerdefiniertes Subnetz und ein NAT-Gateway einrichten, damit Kubernetes-Arbeitslasten (z. B. cert-manager- und Registration Authority-Clients) ausgehenden Traffic sicher an den EJBCA-Server weiterleiten können:

  • Weisen Sie Netzwerkentwicklerrollen auf Projekt- und Organisationsebene zu:

    gdcloud projects add-iam-policy-binding ${GDC_PROJECT_ID} \
  --member=user:${GDC_USER_NAME} \
  --role=cloud-nat-developer

gdcloud projects add-iam-policy-binding ${GDC_PROJECT_ID} \
  --member=user:${GDC_USER_NAME} \
  --role=subnet-project-admin

gdcloud organizations add-iam-policy-binding ${GDC_ORG} \
  --member="user:${GDC_USER_NAME}" \
  --role=subnet-org-admin

  • Erstellen Sie das Subnetz für ausgehenden Traffic:

    kubectl --kubeconfig MANAGEMENT_API_KUBECONFIG apply -f - <<EOF
apiVersion: ipam.gdc.goog/v1
kind: Subnet
metadata:
  name: ejbca-cluster-egress
  namespace: ${GDC_PROJECT_ID}
spec:
  ipv4Request:
    prefixLength: 32
  parentReference:
    name: data-network-segment-${GDC_ZONE}-group
    namespace: platform
    type: SubnetGroup
  type: Leaf
EOF

  • Erstellen Sie die CloudNATGateway, die dem cert-manager-Ausstellerselektor entspricht:

    kubectl --kubeconfig MANAGEMENT_API_KUBECONFIG apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: CloudNATGateway
metadata:
  name: ejbca-egress-gateway
  namespace: ${GDC_PROJECT_ID}
spec:
  subnetRefs:
  - ejbca-cluster-egress
  workloadSelector:
    labelSelector:
      clusters:
        matchLabels:
          kubernetes.io/metadata.name: ${GDC_CLUSTER_NAME}
      workloads:
        matchLabels:
          app.kubernetes.io/name: ejbca-cert-manager-issuer
EOF

Kubernetes-cert-manager-Integration

In diesem Abschnitt binden Sie den benutzerdefinierten EJBCA-cert-manager-Aussteller in den cert-manager-Dienst von GDC ein. So können Sie die automatisierte Bereitstellung, Verlängerung und Lebenszyklusverwaltung von Zertifikaten für Ihre containerisierten Dienste einrichten.

Diagramm zur Integration von EJBCA und cert-manager.

EJBCA für den Aussteller konfigurieren

Zum Einbinden des Ausstellers konfigurieren Sie die erforderlichen Profile, registrieren die Anmeldedaten des Administrationsclients und richten Rollenbindungen auf dem EJBCA-Server ein. Dadurch wird ein sicherer Verwaltungskanal eingerichtet, über den sich cert-manager bei EJBCA authentifizieren und Zertifikate von EJBCA anfordern kann.

Profil für Administratorzertifikat erstellen

Zuerst erstellen Sie in EJBCA ein Zertifikatsprofil, um die technischen Eigenschaften und kryptografischen Einschränkungen (z. B. Algorithmen und Gültigkeitszeiträume) des administrativen Zertifikats zu definieren:

  • Öffnen Sie die EJBCA-Admin-Benutzeroberfläche und rufen Sie CA-Funktionen > Zertifikatsprofile auf.
  • Klonen Sie das Profil ENDUSER und nennen Sie es GDC ADMIN PROFILE.
  • Bearbeiten Sie die GDC ADMIN PROFILE und konfigurieren Sie die folgenden Einstellungen:
    • Verfügbare Schlüsselalgorithmen: RSA
    • Verfügbare Bitlängen: 2048, 3072, 4096
    • Signaturalgorithmus: SHA512WithRSA
    • Gültigkeit: 200d
    • Alternativer Name des Ausstellers: Deaktivieren Sie Verwenden.
    • CRL-Verteilungspunkte: Setzen Sie ein Häkchen bei Verwenden.
    • Von der Zertifizierungsstelle definierten CRL-Verteilungspunkt verwenden: Klicken Sie auf Verwenden.
    • Zugriff auf Informationen zur Zertifizierungsstelle: Setzen Sie ein Häkchen bei Verwenden.
    • Von der Zertifizierungsstelle definierten OCSP-Locator verwenden: Setzen Sie ein Häkchen bei Verwenden.
    • Von der Zertifizierungsstelle definierten Aussteller verwenden: Setzen Sie ein Häkchen bei Verwenden.
    • Verfügbare Zertifizierungsstellen: Wählen Sie GDC Subordinate CA aus.
  • Klicken Sie auf Speichern.

Profil für Administrator-Endentität erstellen

Als Nächstes erstellen Sie ein Endentitätsprofil in EJBCA, um Standardfelder und CA-Zuweisungen zu definieren. Dadurch wird die Registrierung und Ausstellung des Administratorzertifikats vereinfacht:

  • Rufen Sie RA Functions (Registrierungsstellenfunktionen) > End Entity Profiles (Endentitätsprofile) auf.
  • Geben Sie unter Endentitätsprofil hinzufügen GDC ADMIN EE PROFILE ein und klicken Sie auf Profil hinzufügen.
  • Bearbeiten Sie das Profil und konfigurieren Sie die folgenden Einstellungen:
    • Standardzertifikatprofil: GDC ADMIN PROFILE
    • Verfügbare Zertifikatprofile: GDC ADMIN PROFILE
    • Standard-Zertifizierungsstelle: GDC Subordinate CA
    • Verfügbare Zertifizierungsstellen: GDC Subordinate CA
  • Klicken Sie auf Speichern.

Administratorzertifikat registrieren

Nachdem die Profile erstellt wurden, registrieren Sie die administrative Identität über die EJBCA-Registrierungsstelle (RA) und extrahieren den privaten Schlüssel, das öffentliche Zertifikat und die Vertrauenskette, um die physischen Berechtigungsnachweisdateien zu generieren, die für die Authentifizierung von cert-manager erforderlich sind:

  • Rufe den Tab RA Web auf.
  • Klicken Sie auf Neue Anfrage stellen und konfigurieren Sie Folgendes:
    • Zertifikatstyp: GDC ADMIN EE PROFILE
    • Schlüsselpaargenerierung: Durch die Zertifizierungsstelle
    • Schlüsselalgorithmus: RSA 4096 Bit
    • Common Name (CN): cert-manager
    • Nutzername: cert-manager
    • Registrierungscode: abcd
  • Klicken Sie auf PEM-Datei herunterladen und speichern Sie sie als cert-manager.pem.

  • Teilen Sie die PEM-Dateien in drei Dateien auf:

    • client.key (der geheime Schlüssel):

      openssl pkey -in cert-manager.pem -out client.key

    • client.crt (das öffentliche Zertifikat):

      openssl x509 -in cert-manager.pem -out client.crt

    • ca.crt (die Vertrauenskette mit den Zertifikaten der untergeordneten und der Stammzertifizierungsstelle):

      awk '/BEGIN CERTIFICATE/{i++} i>1' cert-manager.pem > ca.crt

Rollen und Zugriffsregeln konfigurieren

Schließlich erstellen Sie eine Administratorrolle in EJBCA und binden sie an die Seriennummer des cert-manager-Zertifikats, damit der Aussteller nur die minimalen Berechtigungen hat, die zum Genehmigen und Anfordern von Zertifikaten erforderlich sind:

  • Rufen Sie in der EJBCA-Admin-Benutzeroberfläche RA Functions > Search End Entities auf.
  • Suchen Sie nach der Endentität cert-manager und notieren Sie sich die Seriennummer des Zertifikats.
  • Rufen Sie Systemfunktionen > Rollen und Zugriffsregeln auf und klicken Sie auf Hinzufügen.
  • Nennen Sie die Rolle cert-manager und fügen Sie ein neues Mitglied mit der Seriennummer hinzu, die Sie sich notiert haben.
  • Klicken Sie auf Zugriffsregeln bearbeiten und konfigurieren Sie die folgenden Berechtigungen:
    • Rollenvorlage: RA-Administratoren
    • Autorisierte Zertifizierungsstellen: GDC Subordinate CA
    • Regeln für Endentitäten: Endentitäten genehmigen, erstellen und bearbeiten
    • Endentitätsprofile: GDC TLS SERVER EE PROFILE
    • Andere Regeln: Audit-Log ansehen deaktivieren
  • Klicken Sie auf Speichern.

GDC-Cluster vorbereiten

Zur Vorbereitung der GDC-Umgebung authentifizieren Sie sich bei Ihrem Standard-Kubernetes-Cluster und speichern die extrahierten EJBCA-Administratoranmeldedaten in Kubernetes-Secrets, damit die Cert-Manager-Aussteller-Pods sicher darauf zugreifen können:

  • Rufen Sie die Standard-Clusteranmeldedaten ab:

    gdcloud clusters get-credentials "${GDC_CLUSTER_NAME}" \
  --standard \
  --project "${GDC_PROJECT_ID}" \
  --zone "${GDC_ZONE}"

  • Erstellen Sie den Ziel-Namespace für den benutzerdefinierten Aussteller:

    kubectl create ns ejbca-issuer-system

  • Stellen Sie das TLS-Authentifizierungs-Secret bereit:

    kubectl create secret tls ejbca-secret \
  -n ejbca-issuer-system \
  --cert=client.crt \
  --key=client.key

  • Stellen Sie das Secret für die EJBCA-Vertrauenskette bereit:

    kubectl create secret generic ejbca-ca-secret \
  -n ejbca-issuer-system \
  --from-file=ca.crt

EJBCA-Aussteller installieren

Zum Konfigurieren der Bereitstellung spiegeln Sie das Container-Image des EJBCA-cert-manager-Ausstellers in Ihrer privaten Harbor-Registry und stellen das Helm-Diagramm bereit. Dadurch wird der benutzerdefinierte Controller instanziiert, der zum Übersetzen von Kubernetes-Zertifikatsanfragen in EJBCA API-Aufrufe erforderlich ist:

  • Erstellen Sie ein Harbor-Image-Pull-Secret im Namespace des Ausstellers:

    # Authenticate with the private Harbor registry
docker --config=./docker-harbor login ${HARBOR_INSTANCE_URL} \
  -u ${HARBOR_ROBOT_ACCOUNT} \
  -p ${HARBOR_ROBOT_SECRET}

kubectl create secret docker-registry ${HARBOR_PULL_SECRET_NAME} \
  --from-file=.dockerconfigjson=./docker-harbor/config.json \
  -n ejbca-issuer-system

  • Spiegeln Sie das offizielle EJBCA-cert-manager-Aussteller-Image in Harbor:

    docker pull keyfactor/ejbca-cert-manager-issuer:latest --platform linux/amd64

docker tag keyfactor/ejbca-cert-manager-issuer:latest \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/ejbca-cert-manager-issuer:latest

docker --config=./docker-harbor push \
  ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/ejbca-cert-manager-issuer:latest

  • Fügen Sie das Helm-Repository hinzu und laden Sie das Diagramm herunter:

    helm repo add ejbca-issuer https://keyfactor.github.io/ejbca-cert-manager-issuer
helm repo update
helm pull ejbca-issuer/ejbca-cert-manager-issuer --untar

  • Stellen Sie das Helm-Diagramm mithilfe des gespiegelten Image-Repositorys bereit:

    helm install ejbca-cert-manager-issuer ./ejbca-cert-manager-issuer \
  --namespace ejbca-issuer-system \
  --set image.repository=${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/ejbca-cert-manager-issuer \
  --set "imagePullSecrets[0].name=${HARBOR_PULL_SECRET_NAME}" \
  --set image.tag=latest

Ausstellerressource erstellen

Als Nächstes richten Sie GDC-RBAC-Berechtigungen ein und stellen eine globale ClusterIssuer-Ressource bereit, die den EJBCA-Server als vertrauenswürdige Signaturquelle im Kubernetes-cert-manager-Framework registriert:

  • Konfigurieren Sie RBAC-Berechtigungen, damit der cert-manager-Controller von GDC den benutzerdefinierten EJBCA-Aussteller verwenden kann:

    kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cert-manager-controller-approve:issuers-ejbca-issuer-keyfactor-com
rules:
- verbs:
  - approve
  apiGroups:
  - cert-manager.io
  resources:
  - signers
  resourceNames:
  - issuers.ejbca-issuer.keyfactor.com/*
  - clusterissuers.ejbca-issuer.keyfactor.com/*
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cert-manager-controller-approve:issuers-ejbca-issuer-keyfactor-com
subjects:
- kind: ServiceAccount
  name: cert-manager
  namespace: cert-manager
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cert-manager-controller-approve:issuers-ejbca-issuer-keyfactor-com
EOF

  • Stellen Sie die globale ClusterIssuer-Ressource bereit:

    kubectl apply -f - <<EOF
apiVersion: ejbca-issuer.keyfactor.com/v1alpha1
kind: ClusterIssuer
metadata:
  name: clusterissuer-ejbca
spec:
  hostname: "${EJBCA_HOSTNAME}"
  ejbcaSecretName: "ejbca-secret"
  caBundleSecretName: "ejbca-ca-secret"
  certificateAuthorityName: "${EJBCA_CA_NAME}"
  certificateProfileName: "${CERTIFICATE_PROFILE_NAME}"
  endEntityProfileName: "${END_ENTITY_PROFILE_NAME}"
  endEntityName: ""
EOF

  • Prüfen Sie den Status des Ausstellers:

    kubectl get clusterissuer.ejbca-issuer.keyfactor.com/clusterissuer-ejbca \
  -o "custom-columns=NAME:.metadata.name,STATUS:.status.conditions[0].message"

    Die Ausgabe sollte so aussehen:

    NAME                  STATUS
clusterissuer-ejbca   Success

Zertifikat anfordern

Zur Überprüfung der Integration stellen Sie eine Standard-Kubernetes-Zertifikatsressource bereit, um den End-to-End-cert-manager-Ablauf zu testen und zu bestätigen, dass EJBCA das angeforderte Zertifikat erfolgreich signiert und bereitstellt:

Erstellen Sie eine Certificate-Testressource, um die erfolgreiche Integration zu prüfen:

kubectl apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: ejbca-test-certificate
  namespace: ${EJBCA_NAMESPACE}
spec:
  commonName: example.com
  secretName: ejbca-certificate
  issuerRef:
    name: clusterissuer-ejbca
    group: ejbca-issuer.keyfactor.com
    kind: ClusterIssuer
EOF

Prüfen Sie, ob das Zertifikat erstellt wurde und bereit ist:

kubectl get certificates.cert-manager.io -n ${EJBCA_NAMESPACE}

Die Ausgabe sollte so aussehen:

NAME                     READY   SECRET              AGE
ejbca-test-certificate   True    ejbca-certificate   12s

Automatisierte ACME mit DNS-01-Identitätsbestätigungen

In diesem Abschnitt konfigurieren Sie den ACME-Dienst von EJBCA und verwenden interne DNS-Ressourcen von GDC, um die Ausstellung von domainvalidierten Zertifikaten zu automatisieren. So können Standard-cert-manager- oder Certbot-Clients Zertifikate mit automatisierten ACME-Standardprotokollen anfordern.

EJBCA für ACME konfigurieren

Zur Vorbereitung des Servers aktivieren Sie den ACME-Dienst in EJBCA und konfigurieren einen ACME-Alias mit einem dedizierten DNS-Resolver. Dadurch wird der EJBCA-Server darauf vorbereitet, DNS-01-Challenge-Antworten in GDC zu verarbeiten und zu validieren:

  • Rufen Sie in der EJBCA-Admin-Benutzeroberfläche Systemkonfiguration > ACME-Konfiguration auf.
  • Klicken Sie auf Hinzufügen und konfigurieren Sie Folgendes:
    • Name: default
    • Profil der Endentität: GDC TLS SERVER EE PROFILE
    • Ausstellung von Platzhalterzertifikaten zulässig: Aktivieren
    • Challenge-Response-MPIC-Validierung – DNS-Kennung – Challenge-Typen: Wählen Sie dns-01 aus.
    • DNS-Resolver: Geben Sie die IP-Adresse Ihres globalen DNS ein.
    • DNSSEC validieren: deaktiviert (da es sich um eine lokale private Umgebung handelt)
  • Klicken Sie auf Speichern.

ACME-Umgebungsvariablen erstellen

In diesem Abschnitt erstellen Sie die folgenden Umgebungsvariablen, um Ihren Certbot-Client zu konfigurieren. Ändern Sie diese Werte nach Bedarf:

# ACME Alias created in the EJBCA configuration
export ACME_ALIAS="default"

# Arbitrary email address used for ACME registration
export ACME_EMAIL="your-email@example.com"

Certbot-Client registrieren

Als Nächstes installieren Sie den Standard-Certbot-Client und registrieren ihn beim privaten ACME-Endpunkt von EJBCA. Dadurch wird das vertrauenswürdige Kundenkonto eingerichtet, das für automatisierte Zertifikatsvorgänge erforderlich ist:

  • Installieren Sie certbot auf Ihrer Workstation. Beispiel für macOS:

    brew install certbot

  • Erstellen Sie lokale Ordner für die Konfiguration und die Logs:

    mkdir -p ./certbot/config ./certbot/work ./certbot/logs

  • Registrieren Sie den Client beim EJBCA-ACME-Verzeichnisendpunkt:

    certbot register \
  --config-dir ./certbot/config \
  --work-dir ./certbot/work \
  --logs-dir ./certbot/logs \
  --server https://${EJBCA_HOSTNAME}/ejbca/acme/${ACME_ALIAS}/directory \
  --email ${ACME_EMAIL} \
  --agree-tos \
  --no-eff-email

Zertifikat mit DNS-Challenge ausstellen

Schließlich führen Sie eine manuelle Certbot-Anfrage aus und stellen eine temporäre GDC-DNS-TXT-Ressource bereit, um die DNS-01-Identitätsbestätigung zu lösen. Dadurch wird Ihre Inhaberschaft der Zieldomain bestätigt und die automatische Zertifikatsausstellung ausgelöst:

  • Führen Sie den Befehl für die manuelle Challenge aus:

    certbot certonly \
  --manual \
  --preferred-challenges dns \
  --key-type rsa \
  --rsa-key-size 2048 \
  --config-dir ./certbot/config \
  --work-dir ./certbot/work \
  --logs-dir ./certbot/logs \
  --server https://${EJBCA_HOSTNAME}/ejbca/acme/${ACME_ALIAS}/directory \
  -d test.${EJBCA_DNS_ZONE}

    Das Terminal wird angehalten und ein Challenge-Wert wird angezeigt. Beispielausgabe:

    Please deploy a DNS TXT record under the name:

_acme-challenge.test.example.internal.

with the following value:

q3pCmzXfIhsTpT4f4JAulHmHaAR3udC_9Wf1G498ER0

Before continuing, verify the TXT record has been deployed.

  • Stellen Sie den TXT-Eintrag mit dem von Certbot bereitgestellten String in Ihrem globalen DNS bereit.

  • Warten Sie etwa 30 Sekunden, bis die DNS-Weitergabe abgeschlossen ist, kehren Sie zum Certbot-Terminal zurück und drücken Sie die Eingabetaste.

    Beispielausgabe:

    Successfully received certificate.
Certificate is saved at:./certbot/config/live/test.example.internal/fullchain.pem
Key is saved at:./certbot/config/live/test.example.internal/privkey.pem
This certificate expires on 2026-11-16.
These files will be updated when the certificate renews.

  • Prüfen Sie, ob das Zertifikat erfolgreich in ./certbot/config/live/test.${EJBCA_DNS_ZONE}/ geschrieben wurde.