Implémentation de référence Keyfactor EJBCA

Présentation

Ce guide explique comment intégrer Keyfactor EJBCA Enterprise (déployé en tant qu'appliance 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 hautement évolutive, robuste 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 à l'intérieur de 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 utiliser la même architecture de CA et les mêmes règles de gestion cohérentes pour les charges de travail exécutées dans leurs environnements GDC isolés.

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

Hypothèses

Avant de suivre ce guide, assurez-vous que les hypothèses suivantes sont respectées :

  • Keyfactor EJBCA est déployé en tant qu'appliance logicielle ou matérielle, et une adresse IP stable est configurée pour le service.
  • Des autorités de certification (CA) racine, subordonnées et de gestion ont été créées dans l'instance EJBCA.
  • Des profils d'entité finale (EE, End Entity) 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 (tels qu'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, où le serveur EJBCA et son module de sécurité matérielle (HSM) sous-jacent sont hébergés en externe, en dehors des limites physiques du GDC, mais sont accessibles via le réseau. Le serveur EJBCA peut être déployé en externe sous forme d'appliance matérielle ou logicielle. 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 :

  • EJBCA Enterprise Server : déployé en externe sous la forme d'un appliance matérielle ou logicielle Keyfactor, hébergeant les autorités de certification (racine et subordonnée) et générant tout le matériel clé de l'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 défis ACME DNS-01.
  • 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 les images de conteneurs mises en miroir (telles que l'émetteur cert-manager EJBCA) pour le déploiement en mode 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 selon vos besoins 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 sur le réseau : Ce guide suppose qu'il est exécuté à partir d'un nœud bastion ayant accès aux API GDC sous air gap et à Internet pour télécharger les images de conteneurs et les manifestes requis. Si vous exécutez cette opération à partir d'une machine sans accès à Internet, vous devez obtenir ces composants 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), puis 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 globale 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 pour l'API globale) :

    alias kg="kubectl --kubeconfig GLOBAL_API_KUBECONFIG"

Créer le cluster standard GDC

Dans cette section, vous allez déployer un cluster Kubernetes standard dans GDC et configurer les rôles d'administrateur de cluster GDC standard, ainsi que 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 standard GDC à 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 conteneur mises en miroir :

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

7. Créez un compte robot Harbor et enregistrez 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 ensemble d'enregistrements afin de mapper le serveur EJBCA externe à un nom de domaine local. Les services à l'intérieur de GDC peuvent ainsi se connecter à l'aide d'un nom d'hôte stable au lieu d'une adresse IP brute :

  • Attribuez le rôle d'administrateur du 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 ResourceRecordSet en pointant vers l'adresse IP de votre appliance 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

Configurer une passerelle NAT de sortie

Ensuite, 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) de router de manière sécurisée le trafic sortant vers le serveur EJBCA :

  • Attribuez des rôles de développeur 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 Kubernetes cert-manager

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

Diagramme d'intégration 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ôle dans 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 administrateur

Vous allez commencer 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'administrateur :

  • Ouvrez l'interface utilisateur d'administration EJBCA, puis accédez à CA Functions > Certificate Profiles.
  • Cloner le profil ENDUSER et le nommer GDC ADMIN PROFILE.
  • Modifiez GDC ADMIN PROFILE et configurez les paramètres suivants :
    • Algorithmes de clé disponibles : RSA
    • Tailles de clés disponibles : 2048, 3072, 4096
    • Algorithme de signature : SHA512WithRSA
    • Validité : 200d
    • Nom alternatif de l'émetteur : Utiliser
    • Points de distribution LRC : cochez Utiliser.
    • Utiliser le point de distribution LRC 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.
    • Utiliser l'émetteur d'autorité de certification défini par l'autorité de certification : cochez Utiliser.
    • Autorités de certification disponibles : sélectionnez GDC Subordinate CA.
  • Cliquez sur Enregistrer.

Créer un profil d'entité finale 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'AC, ce qui simplifie le processus d'enregistrement et d'émission du certificat administratif :

  • Accédez à RA Functions > End Entity Profiles (Fonctions RA > Profils d'entité finale).
  • Sous Ajouter un profil d'entité finale, saisissez GDC ADMIN EE PROFILE, puis cliquez sur 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
    • CA 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 EJBCA Registration Authority (RA), puis vous extrayez la clé privée, le certificat public et la chaîne de confiance pour générer les fichiers de dispositifs d'identification physiques nécessaires à l'authentification de cert-manager :

  • Accédez à l'onglet RA Web.
  • Cliquez sur Faire une nouvelle demande et configurez les éléments suivants :
    • Type de certificat : GDC ADMIN EE PROFILE
    • Génération de la paire de clés : par l'AC
    • 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 (clé secrète) :

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

    • client.crt (certificat public) :

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

    • ca.crt (chaîne de confiance avec les certificats d'autorité de certification subordonnée 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 le liez 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 utilisateur d'administration EJBCA, accédez à Fonctions AR > Rechercher des entités finales.
  • Recherchez l'entité finale cert-manager et notez son numéro de série du certificat.
  • Accédez à Fonctions système > Rôles et règles d'accès, puis cliquez sur Ajouter.
  • Nommez le rôle cert-manager et ajoutez un 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 d'accès suivants :
    • Modèle de rôle : administrateurs RA
    • CA autorisées : GDC Subordinate CA
    • Règles relatives aux entités finales : 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, authentifiez-vous auprès de votre cluster Kubernetes standard et stockez les identifiants administratifs EJBCA extraits dans des secrets Kubernetes, ce qui les rend accessibles de manière sécurisée aux pods de l'é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 vers 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 de l'émetteur

Vous allez ensuite établir des autorisations RBAC GDC et déployer une ressource ClusterIssuer globale, qui enregistre le serveur EJBCA en tant que source de signature fiable dans le framework Kubernetes cert-manager :

  • 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 déployez 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 les 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 au défi DNS-01 dans GDC :

  • Dans l'interface utilisateur d'administration EJBCA, accédez à System Configuration > ACME Configuration.
  • Cliquez sur Ajouter et configurez les éléments suivants :
    • Nom : default
    • Profil de l'entité finale : GDC TLS SERVER EE PROFILE
    • Émission de certificats génériques autorisée : cocher
    • Types de défis pour la validation MPIC de l'identifiant DNS de la réponse au défi : Sélectionnez dns-01.
    • Résolveur DNS : saisissez l'adresse IP de votre DNS global.
    • Valider DNSSEC : désélectionnez cette option (puisqu'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, installez le client Certbot standard et enregistrez-le 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 poste 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 du répertoire 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 du défi DNS

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

  • Exécutez la commande de défi 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 challenge. 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 mondial avec la chaîne fournie par Certbot.

  • Patientez environ 30 secondes pour la propagation DNS, 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 a bien été écrit dans ./certbot/config/live/test.${EJBCA_DNS_ZONE}/.