Implémentation de référence Keyfactor EJBCA

Présentation

Ce guide explique comment intégrer Keyfactor EJBCA Enterprise (déployé en tant qu'appareil externe) en tant qu'autorité de certification (CA) tierce pour Google Distributed Cloud (GDC) air-gapped.

Keyfactor EJBCA Enterprise est une plate-forme d'autorité de certification robuste, hautement évolutive et conforme à la norme FIPS, qui permet aux entreprises de gérer l'infrastructure à clé publique (PKI) dans des environnements hétérogènes.

GDC sous air gap inclut un service d'autorité de certification intégré pour la gestion automatisée des clés et des certificats dans la limite du cloud hébergé. Toutefois, les organisations qui ont standardisé leur infrastructure PKI sur Keyfactor EJBCA pour les charges de travail existantes en dehors de GDC peuvent préférer exploiter la même architecture d'autorité de certification et les mêmes règles de gestion pour les charges de travail exécutées dans leurs environnements GDC sous air gap.

Ce guide explique comment configurer la mise en réseau GDC, le DNS interne et le gestionnaire de certificats Kubernetes pour automatiser la gestion du cycle de vie des certificats (ACME) et permettre l'émission programmatique de volumes élevés à l'aide d'un modèle d'autorité d'enregistrement (RA).

Hypothèses

Avant de poursuivre, assurez-vous que les conditions suivantes sont remplies :

  • Keyfactor EJBCA est déployé en tant qu'appareil logiciel ou matériel, et une adresse IP stable est configurée pour le service.
  • Les autorités de certification (CA) racine, subordonnée et de gestion ont été créées dans l'instance EJBCA.
  • Les profils d'entité finale (EE) ont été configurés (par exemple, pour les certificats de serveur TLS).
  • Les certificats des utilisateurs de l'autorité de certification administrative ont été téléchargés.
  • Les protocoles requis (comme ACME) sont activés sur l'instance EJBCA.
  • Les algorithmes de signature RSA sont utilisés dans ce guide. Vous pouvez modifier l'algorithme de signature en fonction de vos besoins spécifiques ou de ce qui est configuré dans votre instance EJBCA.

Architecture

L'architecture suit le modèle d'autorité de certification externe, dans lequel le serveur EJBCA et son module de sécurité matérielle (HSM) sont hébergés en dehors des limites physiques de GDC, mais sont accessibles via le réseau. Le serveur EJBCA peut être déployé en externe en tant qu'appareil matériel ou logiciel. L'intégration de base décrite dans ce guide nécessite uniquement que le serveur EJBCA externe soit accessible à l'aide d'une adresse IP stable.

Schéma de l'architecture Keyfactor EJBCA.

Voici les principaux composants de cette architecture :

  • Serveur EJBCA Enterprise : déployé en externe en tant qu'appareil matériel ou logiciel Keyfactor, hébergeant les autorités de certification (racine et subordonnée) et générant tout le matériel de clé d'autorité de certification dans un HSM certifié CC EAL4+.
  • Cluster Kubernetes GDC Standard : environnement de calcul exécutant les charges de travail client, cert-manager et les proxys d'intégration.
  • DNS interne GDC : gère les zones DNS privées locales (à l'aide du nom de domaine privé configuré dans les variables d'environnement) utilisées pour résoudre les questions DNS-01 ACME.
  • Passerelle de sortie GDC : dirige le trafic sortant des pods du cluster vers l'adresse IP du serveur EJBCA externe.
  • Registre privé Harbor : héberge des images de conteneurs dupliquées (telles que l'émetteur cert-manager EJBCA) pour un déploiement sous air gap.

Avant de commencer

Avant de commencer l'intégration, assurez-vous que votre environnement GDC répond aux exigences suivantes :

  • Commencez par créer un projet qui servira de conteneur pour toutes les ressources générées tout au long de ce guide.

  • Configurez les variables d'environnement qui seront référencées tout au long de ce guide. Modifiez ces valeurs si nécessaire pour qu'elles correspondent à votre environnement spécifique :

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

  • Remarque concernant le réseau : Ce guide suppose que l'exécution est effectuée à partir d'un nœud bastion qui a accès aux API GDC sous air gap et à Internet pour télécharger les fichiers manifestes et les images de conteneurs requis. Si vous exécutez cette opération à partir d'une machine sans accès à Internet, vous devez obtenir ces éléments séparément (par exemple, en utilisant docker save pour exporter des images à partir d'une machine connectée et docker load pour les importer) et les importer de manière sécurisée dans votre environnement avant de continuer.

Configurer des alias kubectl

Dans cette section, vous allez créer des alias de ligne de commande pratiques pour les API de gestion zonale et globales de GDC :

  • Créez un alias pour l'API de gestion zonale (remplacez MANAGEMENT_API_KUBECONFIG par le chemin d'accès au fichier kubeconfig de l'API de gestion) :

    alias km="kubectl --kubeconfig MANAGEMENT_API_KUBECONFIG"

  • Créez un alias pour l'API globale (remplacez GLOBAL_API_KUBECONFIG par le chemin d'accès au fichier kubeconfig de l'API globale) :

    alias kg="kubectl --kubeconfig GLOBAL_API_KUBECONFIG"

Créer le cluster GDC standard

Dans cette section, vous allez déployer un cluster Kubernetes standard dans GDC, et configurer les rôles d'administrateur de cluster standard GDC et les identifiants du registre de conteneurs Harbor local :

1 Identifiez les types d'images de machines virtuelles disponibles en exécutant la commande suivante :

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

2 Sélectionnez un type de machine approprié pour les nœuds de calcul de votre cluster :

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

3 Créez un cluster standard avec deux nœuds de calcul à l'aide de l'API de gestion zonale :

```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 Une fois le cluster prêt, récupérez ses identifiants :

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

5 Attribuez des rôles d'administrateur de cluster GDC standard à votre utilisateur GDC :

```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 Créez une instance Harbor et un projet Harbor dans GDC pour héberger les images de conteneurs dupliquées :

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

7 Créez un compte de robot Harbor, puis notez son nom d'utilisateur et sa clé secrète.

8 Authentifiez-vous auprès de votre instance Harbor :

```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.

Configuration de l'infrastructure et du réseau

Dans cette section, vous allez configurer l'infrastructure GDC sous-jacente et les paramètres réseau. Cela garantit que vos charges de travail Kubernetes peuvent résoudre le nom de domaine de l'hôte EJBCA externe et acheminer correctement les appels d'API sortants vers son adresse IP.

Configuration du DNS privé dans GDC sous air gap

Pour établir la résolution de domaine, vous déployez une zone DNS privée et un jeu d'enregistrements afin de mapper le serveur EJBCA externe à un nom de domaine local. Cela permet aux services de GDC de se connecter à l'aide d'un nom d'hôte stable au lieu d'une adresse IP brute :

  • Attribuez le rôle d'administrateur de projet DNS géré à votre utilisateur :

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

  • Déployez la ressource ManagedDNSZone globale :

    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

  • Déployez le ResourceRecordSet pointant vers l'adresse IP de votre appareil EJBCA :

    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

Configuration de la passerelle NAT sortante

Ensuite, vous configurez la mise en réseau de sortie GDC en configurant un sous-réseau personnalisé et une passerelle NAT pour permettre aux charges de travail Kubernetes (telles que les clients cert-manager et Registration Authority) d'acheminer de manière sécurisée le trafic sortant vers le serveur EJBCA :

  • Attribuez des rôles de développeur de réseau au niveau du projet et de l'organisation :

    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

  • Créez le sous-réseau de sortie :

    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

  • Créez le CloudNATGateway correspondant au sélecteur d'émetteur cert-manager :

    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

Intégration de cert-manager Kubernetes

Dans cette section, vous allez intégrer l'émetteur cert-manager EJBCA personnalisé au service cert-manager de GDC. Cela vous permet d'établir le provisionnement, le renouvellement et la gestion du cycle de vie automatisés des certificats pour vos services conteneurisés.

Schéma d'intégration d'EJBCA cert-manager.

Configurer EJBCA pour l'émetteur

Pour intégrer l'émetteur, vous devez configurer les profils nécessaires, enregistrer les identifiants du client d'administration et configurer les liaisons de rôles sur le serveur EJBCA. Cela établit un canal d'administration sécurisé qui permet à cert-manager de s'authentifier auprès d'EJBCA et de lui demander des certificats.

Créer un profil de certificat d'administrateur

Vous commencez par établir un profil de certificat dans EJBCA pour définir les propriétés techniques et les contraintes cryptographiques (telles que les algorithmes et les périodes de validité) du certificat d'administration :

  • Ouvrez l'interface administrateur d'EJBCA, puis accédez à CA Functions > Certificate Profiles (Fonctions d'autorité de certification > Profils de certificat).
  • Clonez le profil ENDUSER et nommez-le GDC ADMIN PROFILE.
  • Modifiez GDC ADMIN PROFILE et configurez les paramètres suivants :
    • Algorithmes de clé disponibles : RSA
    • Longueurs de bits disponibles : 2048, 3072, 4096
    • Algorithme de signature : SHA512WithRSA
    • Validité : 200d
    • Issuer Alternative Name (Autre nom de l'émetteur) : décochez Use (Utiliser).
    • Points de distribution de la liste de révocation de certificats : cochez Utiliser.
    • Utiliser le point de distribution de la liste de révocation de certificats (CRL) défini par l'autorité de certification : cochez Utiliser.
    • Accès aux informations de l'autorité : cochez Utiliser.
    • Utiliser le localisateur OCSP défini par l'autorité de certification : cochez Utiliser.
    • Use CA defined CA issuer (Utiliser l'émetteur d'autorité de certification défini par l'autorité de certification) : cochez Use (Utiliser).
    • Autorités de certification disponibles : sélectionnez GDC Subordinate CA.
  • Cliquez sur Enregistrer.

Créer un profil d'entité finale d'administrateur

Ensuite, vous allez créer un profil d'entité finale dans EJBCA pour définir les champs par défaut et les attributions d'autorités de certification, ce qui simplifie le processus d'enregistrement et d'émission du certificat d'administration :

  • Accédez à RA Functions > End Entity Profiles (Fonctions RA > Profils d'entité de fin).
  • Sous Add End Entity Profile (Ajouter un profil d'entité finale), saisissez GDC ADMIN EE PROFILE, puis cliquez sur Add Profile (Ajouter un profil).
  • Modifiez le profil et configurez les paramètres suivants :
    • Profil de certificat par défaut : GDC ADMIN PROFILE
    • Profils de certificat disponibles : GDC ADMIN PROFILE
    • Autorité de certification par défaut : GDC Subordinate CA
    • Autorités de certification disponibles : GDC Subordinate CA
  • Cliquez sur Enregistrer.

Enregistrer un certificat d'administrateur

Une fois les profils établis, vous enregistrez l'identité administrative à l'aide de l'interface de l'autorité d'enregistrement (RA) EJBCA et extrayez la clé privée, le certificat public et la chaîne de confiance pour générer les fichiers d'identifiants physiques nécessaires à l'authentification de cert-manager :

  • Accédez à l'onglet RA Web.
  • Cliquez sur Effectuer une nouvelle demande et configurez les éléments suivants :
    • Type de certificat : GDC ADMIN EE PROFILE
    • Génération de paires de clés : par l'autorité de certification
    • Algorithme de clé : RSA 4 096 bits
    • Nom commun (CN) : cert-manager
    • Nom d'utilisateur : cert-manager
    • Code d'enregistrement : abcd
  • Cliquez sur Télécharger le fichier PEM et enregistrez-le sous le nom cert-manager.pem.

  • Divisez les fichiers PEM en trois fichiers :

    • client.key (la clé secrète) :

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

    • client.crt (le certificat public) :

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

    • ca.crt (la chaîne de confiance avec les certificats CA subordonnés et racine) :

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

Configurer des rôles et des règles d'accès

Enfin, vous créez un rôle d'administrateur dans EJBCA et vous l'associez au numéro de série du certificat cert-manager pour vous assurer que l'émetteur ne dispose que de l'ensemble minimal d'autorisations requises pour approuver et demander des certificats :

  • Dans l'interface administrateur d'EJBCA, accédez à RA Functions > Search End Entities (Fonctions RA > Rechercher des entités de fin).
  • Recherchez l'entité de fin cert-manager et notez son numéro de série de certificat.
  • Accédez à System Functions > Roles and Access Rules (Fonctions système > Rôles et règles d'accès), puis cliquez sur Add (Ajouter).
  • Nommez le rôle cert-manager et ajoutez un nouveau membre à l'aide du numéro de série que vous avez enregistré.
  • Cliquez sur Modifier les règles d'accès et configurez les droits suivants :
    • Modèle de rôle : Administrateurs d'AR
    • Autorités de certification autorisées : GDC Subordinate CA
    • Règles d'entité finale : approuver, créer et modifier des entités finales
    • Profils d'entité finale : GDC TLS SERVER EE PROFILE
    • Autres règles : décochez Afficher le journal d'audit.
  • Cliquez sur Enregistrer.

Préparer le cluster GDC

Pour préparer l'environnement GDC, vous vous authentifiez auprès de votre cluster Kubernetes standard et stockez les identifiants d'administration EJBCA extraits dans des secrets Kubernetes, ce qui les rend accessibles de manière sécurisée aux pods d'émetteur cert-manager :

  • Récupérez les identifiants du cluster standard :

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

  • Créez l'espace de noms cible pour l'émetteur personnalisé :

    kubectl create ns ejbca-issuer-system

  • Déployez le secret d'authentification TLS :

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

  • Déployez le secret de la chaîne de confiance EJBCA :

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

Installer l'émetteur EJBCA

Pour configurer le déploiement, vous dupliquez l'image de conteneur de l'émetteur cert-manager EJBCA dans votre registre Harbor privé et déployez le chart Helm. Cela instancie le contrôleur personnalisé requis pour traduire les demandes de certificat Kubernetes en appels d'API EJBCA :

  • Créez un secret d'extraction d'image Harbor dans l'espace de noms de l'émetteur :

    # 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

  • Mettez en miroir l'image officielle de l'émetteur cert-manager EJBCA dans 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

  • Ajoutez le dépôt Helm et téléchargez le chart :

    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

  • Déployez le chart Helm à l'aide du dépôt d'images dupliqué :

    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

Créer la ressource d'émetteur

Ensuite, vous établissez des autorisations RBAC GDC et déployez une ressource ClusterIssuer globale, qui enregistre le serveur EJBCA en tant que source de signature de confiance dans le framework cert-manager Kubernetes :

  • Configurez les autorisations RBAC pour permettre au contrôleur cert-manager de GDC d'utiliser l'émetteur EJBCA personnalisé :

    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

  • Déployez la ressource ClusterIssuer globale :

    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

  • Vérifiez l'état de l'émetteur :

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

    Le résultat doit se présenter comme suit :

    NAME                  STATUS
clusterissuer-ejbca   Success

Demander un certificat

Pour vérifier l'intégration, vous allez déployer une ressource de certificat Kubernetes standard afin de tester le flux cert-manager de bout en bout et de confirmer qu'EJBCA signe et provisionne correctement le certificat demandé :

Créez une ressource Certificate de test pour vérifier que l'intégration a réussi :

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

Vérifiez que le certificat a été créé et qu'il est prêt :

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

Le résultat doit se présenter comme suit :

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

ACME automatisé avec des défis DNS-01

Dans cette section, vous allez configurer le service ACME d'EJBCA et utiliser les ressources DNS internes de GDC pour automatiser l'émission de certificats validés par domaine. Cela permet aux clients cert-manager ou Certbot standards de demander des certificats à l'aide de protocoles ACME automatisés standards.

Configurer EJBCA pour ACME

Pour préparer le serveur, vous devez activer le service ACME dans EJBCA et configurer un alias ACME avec un résolveur DNS dédié. Cela prépare le serveur EJBCA à traiter et à valider les réponses de test DNS-01 dans GDC :

  • Dans l'interface administrateur d'EJBCA, accédez à System Configuration > ACME Configuration (Configuration du système > Configuration ACME).
  • Cliquez sur Ajouter et configurez les éléments suivants :
    • Nom : default
    • Profil d'entité finale : GDC TLS SERVER EE PROFILE
    • Émission de certificats génériques autorisée : cochez cette option.
    • Types de questions d'identification DNS pour la validation MPIC de la réponse à la question : sélectionnez dns-01.
    • Résolveur DNS : saisissez l'adresse IP de votre DNS global.
    • Valider DNSSEC : désélectionnez cette option (car il s'agit d'un environnement privé local).
  • Cliquez sur Enregistrer.

Créer des variables d'environnement ACME

Dans cette section, vous allez créer les variables d'environnement suivantes pour configurer votre client Certbot. Modifiez ces valeurs si nécessaire :

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

Enregistrer le client Certbot

Ensuite, vous installez le client Certbot standard et l'enregistrez auprès du point de terminaison ACME privé d'EJBCA. Cela établit le compte client de confiance nécessaire pour effectuer des opérations de certificat automatisées :

  • Installez certbot sur votre station de travail. Par exemple, pour macOS :

    brew install certbot

  • Créez des dossiers locaux pour la configuration et les journaux :

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

  • Enregistrez le client auprès du point de terminaison de l'annuaire ACME EJBCA :

    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

Émettre un certificat à l'aide d'un test DNS

Enfin, vous exécutez une requête Certbot manuelle et déployez une ressource TXT DNS GDC temporaire pour résoudre le test DNS-01. Cela valide votre propriété du domaine cible et déclenche l'émission automatique du certificat :

  • Exécutez la commande de test manuel :

    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}

    Le terminal s'arrête et affiche une valeur de test. Exemple de résultat :

    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.

  • Déployez l'enregistrement TXT sur votre DNS global avec la chaîne fournie par Certbot.

  • Attendez environ 30 secondes que la propagation DNS s'effectue, revenez au terminal Certbot et appuyez sur Entrée.

    Exemple de résultat :

    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.

  • Vérifiez que le certificat est bien écrit dans ./certbot/config/live/test.${EJBCA_DNS_ZONE}/.