Keyfactor EJBCA-Referenzimplementierung

Übersicht

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

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

GDC mit Air Gap umfasst 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, ziehen es jedoch möglicherweise vor, dieselbe konsistente CA-Architektur und dieselben Verwaltungsrichtlinien für Arbeitslasten zu verwenden, die in ihren Air-Gap-GDC-Umgebungen ausgeführt werden.

In diesem Leitfaden wird gezeigt, wie Sie die GDC-Netzwerkfunktionen, den internen DNS und Kubernetes cert-manager konfigurieren, um die Zertifikatslebenszyklusverwaltung (ACME) zu automatisieren und die programmgesteuerte Ausstellung in großem Umfang mithilfe eines RA-Musters (Registration Authority) zu unterstützen.

Annahmen

Bevor Sie mit dieser Anleitung fortfahren, sollten Sie prüfen, ob die folgenden Voraussetzungen erfüllt sind:

  • 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 einer externen Zertifizierungsstelle, bei dem der EJBCA-Server und das zugehörige Hardwaresicherheitsmodul (HSM) extern außerhalb der physischen GDC-Grenzen gehostet werden, aber über das Netzwerk erreichbar sind. Der EJBCA-Server kann extern als Hardware- oder Software-Appliance bereitgestellt werden. Für die in dieser Anleitung beschriebene Kernintegration ist nur erforderlich, dass der externe EJBCA-Server über eine stabile IP-Adresse erreichbar ist.

Architekturdiagramm für Keyfactor EJBCA.

Zu den wichtigsten Komponenten dieser Architektur gehören:

  • EJBCA Enterprise Server: Wird extern als Keyfactor-Hardware- oder Software-Appliance bereitgestellt, in der sich die Zertifizierungsstellen (Stamm- und untergeordnete Zertifizierungsstellen) befinden und in der das gesamte CA-Schlüsselmaterial in einem CC EAL4+-zertifizierten HSM generiert wird.
  • GDC Standard Kubernetes-Cluster: Die Rechenumgebung, in der Kundenarbeitslasten, cert-manager und Integrationsproxys ausgeführt werden.
  • GDC Internal DNS: Verwaltet lokale private DNS-Zonen (mit dem in den Umgebungsvariablen konfigurierten privaten Domainnamen), die zum Auflösen von ACME DNS-01-Herausforderungen verwendet werden.
  • GDC-Ausgangsgateway: Leitet ausgehenden Traffic von Cluster-Pods an die externe EJBCA-Server-IP-Adresse weiter.
  • Harbor Private Registry: Hier werden gespiegelte Container-Images (z. B. der EJBCA-Cert-Manager-Aussteller) für die Bereitstellung in Umgebungen ohne Internetverbindung gehostet.

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 dieser Anleitung generiert werden.

  • Konfigurieren Sie Umgebungsvariablen, auf die in diesem Leitfaden verwiesen wird. Passen Sie diese Werte nach Bedarf an Ihre spezifische Umgebung an:

    # 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"

  • Hinweis zum Netzwerk: In dieser Anleitung wird davon ausgegangen, dass sie von einem Bastion-Knoten aus ausgeführt wird, der Zugriff auf die GDC-Air-Gap-APIs und auf das Internet hat, um die erforderlichen Manifeste und Container-Images herunterzuladen. Wenn Sie diesen Befehl auf einem Computer ohne Internetzugang ausführen, müssen Sie diese Assets separat abrufen (z. B. mit docker save, um Bilder 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-Aliase für die zonalen Verwaltungs- und globalen APIs von GDC:

  • Erstellen Sie einen Alias für die zonale Management-API (ersetzen Sie MANAGEMENT_API_KUBECONFIG durch den Pfad zur kubeconfig für die Management-API):

    alias km="kubectl --kubeconfig MANAGEMENT_API_KUBECONFIG"

  • Erstellen Sie einen Alias für die globale API (ersetzen Sie GLOBAL_API_KUBECONFIG durch den Pfad zur kubeconfig für die globale API):

    alias kg="kubectl --kubeconfig GLOBAL_API_KUBECONFIG"

GDC-Standardcluster erstellen

In diesem Abschnitt stellen Sie einen Standard-Kubernetes-Cluster in GDC bereit und konfigurieren Administratorrollen für GDC-Standardcluster und lokale Anmeldedaten für die Harbor-Containerregistrierung:

1. Verfügbare VM-Imagetypen ermitteln:

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

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

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

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

```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 nach der Bereitstellung des Clusters die Anmeldedaten ab:

```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 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-Schlüssel.

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 zugehörige IP-Adresse weiterleiten können.

Einrichtung von privatem DNS in GDC mit Air Gap

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 Roh-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 ResourceRecordSet bereit und verweisen Sie auf die IP-Adresse Ihrer EJBCA-Appliance:

    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 Netzwerk von GDC, 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

  • Egress-Subnetz erstellen:

    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 das CloudNATGateway, das 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

Einbindung von Kubernetes cert-manager

In diesem Abschnitt binden Sie den benutzerdefinierten EJBCA-cert-manager-Aussteller in den cert-manager-Dienst von GDC ein. So können Sie die automatische Zertifikatbereitstellung, ‑verlängerung und ‑lebenszyklusverwaltung für Ihre containerisierten Dienste einrichten.

Diagramm zur EJBCA-Cert-Manager-Integration

EJBCA für den Aussteller konfigurieren

Um den Aussteller zu integrieren, konfigurieren Sie die erforderlichen Profile, registrieren die Anmeldedaten des Verwaltungsclients und richten Rollenbindungen auf dem EJBCA-Server ein. Dadurch wird ein sicherer administrativer Kanal eingerichtet, über den cert-manager sich bei EJBCA authentifizieren und Zertifikate anfordern kann.

Administratorzertifikatprofil erstellen

Zuerst erstellen Sie in EJBCA ein Zertifikatprofil, 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 UI und rufen Sie CA Functions > Certificate Profiles 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: 2.048, 3.072, 4.096
    • Signaturalgorithmus: SHA512WithRSA
    • Gültigkeit: 200d
    • Alternativer Name des Ausstellers: Verwenden
    • CRL-Verteilungspunkte: Verwenden muss aktiviert sein.
    • Von der Zertifizierungsstelle definierte CRL-Verteilungspunkte verwenden: Klicken Sie auf Verwenden.
    • Zugriff auf Zertifizierungsstelleninfos: Verwenden muss aktiviert sein.
    • CA-definierten OCSP-Locator verwenden: Aktivieren Sie Verwenden.
    • Von CA definierten CA-Aussteller verwenden: Verwenden aktivieren
    • Verfügbare CAs: Wählen Sie GDC Subordinate CA aus.
  • Klicken Sie auf Speichern.

Administrator-Endentitätsprofil erstellen

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

  • Rufen Sie RA Functions > End Entity Profiles auf.
  • Geben Sie unter End-Entity-Profil 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 Sie die Profile eingerichtet haben, registrieren Sie die administrative Identität über die EJBCA Registration Authority (RA)-Schnittstelle 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:

  • Rufen Sie den Tab RA Web auf.
  • Klicken Sie auf Neue Anfrage stellen und konfigurieren Sie Folgendes:
    • Zertifikattyp: GDC ADMIN EE PROFILE
    • Generierung von Schlüsselpaaren: durch die Zertifizierungsstelle
    • Schlüsselalgorithmus: RSA 4.096 Bit
    • Allgemeiner 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 UI 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.
  • Geben Sie der Rolle den Namen cert-manager und fügen Sie ein neues Mitglied mit der von Ihnen notierten Seriennummer hinzu.
  • 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
    • End Entity Profiles (Endentitätsprofile): GDC TLS SERVER EE PROFILE
    • Andere Regeln: Klicken Sie auf Audit-Log ansehen.
  • Klicken Sie auf Speichern.

GDC-Cluster vorbereiten

Zur Vorbereitung der GDC-Umgebung authentifizieren Sie sich mit Ihrem Standard-Kubernetes-Cluster und speichern die extrahierten EJBCA-Administratoranmeldedaten in Kubernetes-Secrets, sodass sie für die cert-manager-Aussteller-Pods sicher zugänglich sind:

  • Standard-Clusteranmeldedaten abrufen:

    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 Secret für die TLS-Authentifizierung bereit:

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

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

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

EJBCA-Aussteller installieren

Um die Bereitstellung zu konfigurieren, spiegeln Sie das EJBCA-Cert-Manager-Aussteller-Container-Image in Ihrer privaten Harbor-Registry und stellen das Helm-Diagramm bereit. Dadurch wird der benutzerdefinierte Controller instanziiert, der erforderlich ist, um Kubernetes-Zertifikatanfragen in EJBCA-API-Aufrufe zu übersetzen:

  • Erstellen Sie ein Harbor-Secret zum Abrufen von Images 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 mit dem gespiegelten Image-Repository 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, mit der der EJBCA-Server als vertrauenswürdige Signaturquelle im Kubernetes-cert-manager-Framework registriert wird:

  • 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 Ausstellerstatus:

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

    Die Ausgabe sollte Folgendes enthalten:

    NAME                  STATUS
clusterissuer-ejbca   Success

Zertifikat anfordern

Zur Überprüfung der Integration stellen Sie eine standardmäßige Kubernetes-Zertifikatsressource bereit, um den End-to-End-Ablauf von cert-manager 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 überprü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 Folgendes enthalten:

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

Automatisierte ACME-Identitätsbestätigung 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 standardmäßigen automatisierten ACME-Protokollen anfordern.

EJBCA für ACME konfigurieren

Um den Server vorzubereiten, aktivieren Sie den ACME-Dienst in EJBCA und konfigurieren Sie 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-Administratoroberfläche System Configuration > ACME Configuration auf.
  • Klicken Sie auf Hinzufügen und konfigurieren Sie Folgendes:
    • Name: default
    • End-Entity-Profil: GDC TLS SERVER EE PROFILE
    • Wildcard Certificate Issuance Allowed (Ausstellung von Platzhalterzertifikaten zulässig): Aktiviert
    • Challenge-Response-MPIC-Validierung – DNS-Identifier-Challenge-Typen: Wählen Sie dns-01 aus.
    • DNS-Resolver: Geben Sie die IP-Adresse Ihres globalen DNS ein.
    • DNSSEC validieren: nicht erforderlich (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 die automatische Zertifikatsverwaltung 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-Herausforderung zu lösen. Dadurch wird Ihre Inhaberschaft der Zieldomain bestätigt und die automatische Zertifikatausstellung 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 hält an und zeigt einen Challenge-Wert an. 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-Weiterleitung erfolgt ist. Kehren Sie dann 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.