Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Implementazione di riferimento di Keyfactor EJBCA

Panoramica

Questa guida illustra l'integrazione di Keyfactor EJBCA Enterprise (eseguito il deployment come appliance esterna) come autorità di certificazione (CA) di terze parti per Google Distributed Cloud (GDC) air-gapped.

Keyfactor EJBCA Enterprise è una piattaforma di autorità di certificazione altamente scalabile, solida e conforme allo standard FIPS che consente alle organizzazioni di gestire l'infrastruttura a chiave pubblica (PKI) in ambienti eterogenei.

GDC con air gap include un servizio Certificate Authority integrato per la gestione automatizzata di chiavi e certificati all'interno del confine del cloud in hosting. Tuttavia, le organizzazioni che hanno standardizzato la propria infrastruttura PKI su Keyfactor EJBCA per i workload esistenti al di fuori di GDC potrebbero preferire l'utilizzo della stessa architettura CA e delle stesse policy di gestione coerenti per i workload in esecuzione all'interno dei propri ambienti GDC con air gap.

Questa guida mostra come configurare il networking GDC, il DNS interno e il cert-manager di Kubernetes per automatizzare la gestione del ciclo di vita dei certificati (ACME) e supportare l'emissione programmatica di volumi elevati utilizzando un pattern di autorità di registrazione (RA).

Ipotesi

Prima di procedere con questa guida, assicurati che siano soddisfatti i seguenti presupposti:

Keyfactor EJBCA viene distribuito come appliance software o hardware e per il servizio viene configurato un indirizzo IP stabile.
Le autorità di certificazione (CA) radice, subordinate e di gestione sono state create nell'istanza EJBCA.
Sono stati configurati i profili delle entità finali (EE), ad esempio per i certificati del server TLS.
I certificati per gli utenti CA amministrativi sono stati scaricati.
I protocolli richiesti (come ACME) sono abilitati nell'istanza EJBCA.
In questa guida vengono utilizzati gli algoritmi di firma RSA. Puoi modificare l'algoritmo di firma in base ai tuoi requisiti specifici o a ciò che è configurato nella tua istanza EJBCA.

Architettura

L'architettura segue il modello di autorità di certificazione esterna, in cui il server EJBCA e il relativo modulo di sicurezza hardware (HSM) di supporto sono ospitati esternamente al di fuori dei confini fisici di GDC, ma sono accessibili dalla rete. Il server EJBCA può essere distribuito esternamente come appliance hardware o software. L'integrazione di base descritta in questa guida richiede solo che il server EJBCA esterno sia raggiungibile utilizzando un indirizzo IP stabile.

Diagramma dell'architettura di Keyfactor EJBCA.

I componenti chiave di questa architettura includono:

EJBCA Enterprise Server: viene eseguito il deployment esternamente come appliance hardware o software Keyfactor, che ospita le CA (principale e subordinata) e genera tutto il materiale delle chiavi CA all'interno di un HSM certificato CC EAL4+.
Cluster Kubernetes GDC Standard: l'ambiente di computing che esegue i workload dei clienti, cert-manager e i proxy di integrazione.
DNS interno di GDC: gestisce le zone DNS private locali (utilizzando il nome di dominio privato configurato nelle variabili di ambiente) utilizzate per risolvere le sfide DNS-01 ACME.
Gateway in uscita GDC: indirizza il traffico in uscita dai pod del cluster all'indirizzo IP del server EJBCA esterno.
Registry privato Harbor: ospita le immagini container sottoposte a mirroring (come l'emittente cert-manager EJBCA) per il deployment con air gap.

Prima di iniziare

Prima di iniziare l'integrazione, assicurati che il tuo ambiente GDC soddisfi i seguenti requisiti:

Innanzitutto, crea un progetto che fungerà da contenitore per tutte le risorse generate in questa guida.

Configura le variabili di ambiente a cui verrà fatto riferimento in questa guida. Modifica questi valori in base alle esigenze del tuo ambiente specifico:

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

Nota sulla rete: questa guida presuppone che l'esecuzione avvenga da un nodo bastion che ha accesso alle API GDC con air gap e a internet per scaricare i manifest e le immagini container richiesti. Se esegui questa operazione da una macchina senza accesso a internet, devi ottenere questi asset separatamente (ad esempio, utilizzando docker save per esportare le immagini da una macchina connessa e docker load per importarle) e caricarli in modo sicuro nel tuo ambiente prima di procedere.

Configura gli alias kubectl

In questa sezione, crei comodi alias della riga di comando per le API di gestione a livello di zona e globali di GDC:

Crea un alias per l'API di gestione a livello di zona (sostituisci MANAGEMENT_API_KUBECONFIG con il percorso del kubeconfig per l'API di gestione):
```
alias km="kubectl --kubeconfig MANAGEMENT_API_KUBECONFIG"
```
Crea un alias per l'API globale (sostituisci GLOBAL_API_KUBECONFIG con il percorso del kubeconfig per l'API globale):
```
alias kg="kubectl --kubeconfig GLOBAL_API_KUBECONFIG"
```

Crea il cluster GDC standard

In questa sezione, esegui il deployment di un cluster Kubernetes standard all'interno di GDC e configuri i ruoli di amministratore del cluster standard GDC e le credenziali del Container Registry Harbor locale:

1 Identifica i tipi di immagini delle macchine virtuali disponibili eseguendo:

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

2 Seleziona un tipo di macchina appropriato per i nodi worker del cluster:

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

3 Crea un cluster standard con due nodi worker utilizzando l'API di gestione a livello di zona:

```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 Quando il cluster è pronto, recupera le relative credenziali:

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

5 Assegna i ruoli di amministratore del cluster standard GDC al tuo utente 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 Crea un'istanza Harbor e un progetto Harbor in GDC per ospitare le immagini container sottoposte a mirroring:

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

7 Crea un account robot Harbor e registra il nome utente e la chiave secret.

8 Esegui l'autenticazione con l'istanza 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.

Configurazione dell'infrastruttura e della rete

In questa sezione configurerai l'infrastruttura GDC e le impostazioni della rete sottostanti. In questo modo, i workload Kubernetes possono risolvere il nome di dominio host EJBCA esterno e instradare correttamente le chiamate API in uscita al relativo indirizzo IP.

Configurazione del DNS privato in GDC con air gap

Per stabilire la risoluzione del dominio, esegui il deployment di una zona DNS privata e di un set di record per mappare il server EJBCA esterno a un nome di dominio locale, consentendo ai servizi all'interno di GDC di connettersi utilizzando un nome host stabile anziché un indirizzo IP non elaborato:

Assegna il ruolo Amministratore progetto DNS gestito al tuo utente:

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

Esegui il deployment della risorsa 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

Esegui il deployment di ResourceRecordSet che punta all'indirizzo IP della tua 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

Configurazione del gateway NAT in uscita

Successivamente, configura il networking in uscita di GDC impostando una subnet personalizzata e un gateway NAT per consentire ai workload Kubernetes (come i client cert-manager e dell'autorità di registrazione) di instradare in modo sicuro il traffico in uscita al server EJBCA:

Assegna i ruoli di Network Developer a livello di progetto e di organizzazione:

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

Crea la subnet in uscita:

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

Crea il CloudNATGateway corrispondente al selettore dell'emittente 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

Integrazione di cert-manager di Kubernetes

In questa sezione, integrerai l'emittente cert-manager EJBCA personalizzato con il servizio cert-manager di GDC. In questo modo, puoi configurare il provisioning, il rinnovo e la gestione del ciclo di vita dei certificati automatici per i tuoi servizi containerizzati.

Diagramma di integrazione di cert-manager di EJBCA.

Configura EJBCA per l'emittente

Per integrare l'emittente, configura i profili necessari, registra la credenziale client di amministrazione e configura le associazioni dei ruoli all'interno del server EJBCA. In questo modo viene stabilito un canale amministrativo sicuro che consente a cert-manager di autenticarsi con EJBCA e richiedere certificati.

Crea profilo certificato amministratore

Per iniziare, devi creare un profilo del certificato all'interno di EJBCA per definire le proprietà tecniche e i vincoli crittografici (come algoritmi e periodi di validità) del certificato amministrativo:

Apri l'interfaccia utente amministratore di EJBCA, vai a CA Functions (Funzioni CA) > Certificate Profiles (Profili certificato).
Clona il profilo ENDUSER e assegnagli il nome GDC ADMIN PROFILE.
Modifica GDC ADMIN PROFILE e configura le seguenti impostazioni:
- Algoritmi delle chiavi disponibili: RSA
- Lunghezze in bit disponibili: 2048, 3072, 4096
- Signature Algorithm (Algoritmo di firma): SHA512WithRSA
- Validità: 200d
- Issuer Alternative Name (Nome alternativo emittente): deseleziona Use (Utilizza)
- Punti di distribuzione CRL: seleziona Utilizza
- Utilizza il punto di distribuzione CRL definito dalla CA: seleziona Utilizza.
- Accesso alle informazioni sull'autorità: seleziona Utilizza
- Utilizza il localizzatore OCSP definito dalla CA: seleziona Utilizza.
- Utilizza l'emittente CA definito dalla CA: seleziona Utilizza
- CA disponibili: seleziona GDC Subordinate CA
Fai clic su Salva.

Crea profilo entità finale amministratore

Successivamente, crea un profilo di entità finale in EJBCA per definire i campi predefiniti e le assegnazioni delle CA, semplificando il processo di registrazione e rilascio del certificato amministrativo:

Vai a RA Functions (Funzioni RA) > End Entity Profiles (Profili entità finale).
In Aggiungi profilo entità finale, inserisci GDC ADMIN EE PROFILE e fai clic su Aggiungi profilo.
Modifica il profilo e configura le seguenti impostazioni:
- Profilo certificato predefinito: GDC ADMIN PROFILE
- Profili certificato disponibili: GDC ADMIN PROFILE
- CA predefinita: GDC Subordinate CA
- CA disponibili: GDC Subordinate CA
Fai clic su Salva.

Registra il certificato amministratore

Una volta stabiliti i profili, registra l'identità amministrativa utilizzando l'interfaccia dell'autorità di registrazione (RA) EJBCA ed estrai la chiave privata, il certificato pubblico e la catena di attendibilità per generare i file delle credenziali fisiche necessari per autenticare cert-manager:

Vai alla scheda RA Web.
Fai clic su Crea nuova richiesta e configura:
- Tipo di certificato: GDC ADMIN EE PROFILE
- Generazione della coppia di chiavi: da parte della CA
- Algoritmo chiave: RSA a 4096 bit
- Nome comune (CN): cert-manager
- Nome utente: cert-manager
- Codice di registrazione: abcd
Fai clic su Scarica PEM e salvalo come cert-manager.pem.

Suddividi i file PEM in tre file:

client.key (la chiave segreta):

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

client.crt (il certificato pubblico):

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

ca.crt (la catena di attendibilità con i certificati CA subordinati e radice):
```
awk '/BEGIN CERTIFICATE/{i++} i>1' cert-manager.pem > ca.crt
```

Configura ruoli e regole di accesso

Infine, crei un ruolo amministrativo in EJBCA e lo associ al numero di serie del certificato cert-manager per assicurarti che l'emittente disponga solo del set minimo di autorizzazioni necessarie per approvare e richiedere i certificati:

Nell'interfaccia utente amministratore di EJBCA, vai a RA Functions (Funzioni RA) > Search End Entities (Cerca entità finali).
Cerca l'entità finale cert-manager e registra il relativo numero di serie del certificato.
Vai a System Functions (Funzioni di sistema) > Roles and Access Rules (Ruoli e regole di accesso) e fai clic su Add (Aggiungi).
Assegna al ruolo il nome cert-manager e aggiungi un nuovo membro utilizzando il numero di serie che hai registrato.
Fai clic su Modifica regole di accesso e configura i seguenti privilegi:
- Modello di ruolo: Amministratori RA
- CA autorizzate: GDC Subordinate CA
- Regole per le entità finali: approva, crea e modifica le entità finali
- Profili entità finale: GDC TLS SERVER EE PROFILE
- Altre regole: deseleziona Visualizza audit log
Fai clic su Salva.

Prepara il cluster GDC

Per preparare l'ambiente GDC, esegui l'autenticazione con il tuo cluster Kubernetes standard e archivia le credenziali amministrative EJBCA estratte all'interno dei secret di Kubernetes, rendendole accessibili in modo sicuro ai pod dell'emittente cert-manager:

Recupera le credenziali del cluster standard:

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

Crea lo spazio dei nomi di destinazione per l'emittente personalizzato:
```
kubectl create ns ejbca-issuer-system
```

Esegui il deployment del secret di autenticazione TLS:

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

Esegui il deployment del secret della catena di attendibilità EJBCA:

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

Installa l'emittente EJBCA

Per configurare il deployment, esegui il mirroring dell'immagine container dell'emittente cert-manager EJBCA nel tuo registry Harbor privato ed esegui il deployment del grafico Helm. In questo modo viene creata un'istanza del controller personalizzato necessario per tradurre le richieste di certificato Kubernetes in chiamate API EJBCA:

Crea un secret di pull dell'immagine Harbor nello spazio dei nomi dell'emittente:

# 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

Esegui il mirroring dell'immagine ufficiale dell'emittente cert-manager EJBCA su 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

Aggiungi il repository Helm e scarica il grafico:

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

Esegui il deployment del grafico Helm utilizzando il repository di immagini sottoposto a mirroring:

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

Crea la risorsa emittente

Successivamente, stabilisci le autorizzazioni RBAC di GDC ed esegui il deployment di una risorsa ClusterIssuer globale, che registra il server EJBCA come origine di firma attendibile all'interno del framework cert-manager di Kubernetes:

Configura le autorizzazioni RBAC per consentire al controller cert-manager di GDC di utilizzare l'emittente EJBCA personalizzato:

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

Esegui il deployment della risorsa 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

Verifica lo stato dell'emittente:

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

L'output dovrebbe mostrare:

NAME                  STATUS
clusterissuer-ejbca   Success

Richiedi un certificato

Per verificare l'integrazione, esegui il deployment di una risorsa Certificate Kubernetes standard per testare il flusso cert-manager end-to-end e confermare che EJBCA firma ed esegue il provisioning del certificato richiesto:

Crea una risorsa Certificate di test per verificare che l'integrazione sia riuscita:

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

Verifica che il certificato sia stato creato e sia pronto:

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

L'output dovrebbe mostrare:

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

ACME automatizzato con verifiche DNS-01

In questa sezione, configurerai il servizio ACME di EJBCA e utilizzerai le risorse DNS interne di GDC per automatizzare l'emissione di certificati convalidati dal dominio. In questo modo, i client cert-manager o Certbot standard possono richiedere i certificati utilizzando i protocolli ACME automatizzati standard.

Configura EJBCA per ACME

Per preparare il server, attiva il servizio ACME all'interno di EJBCA e configura un alias ACME con un resolver DNS dedicato. In questo modo, il server EJBCA viene preparato per elaborare e convalidare le risposte alle challenge DNS-01 all'interno di GDC:

Nell'interfaccia utente amministratore di EJBCA, vai a System Configuration (Configurazione di sistema) > ACME Configuration (Configurazione ACME).
Fai clic su Aggiungi e configura quanto segue:
- Nome: default
- Profilo dell'entità finale: GDC TLS SERVER EE PROFILE
- Wildcard Certificate Issuance Allowed: Check
- Tipi di verifica dell'identificatore DNS di convalida MPIC di Challenge Response: Seleziona dns-01
- Resolver DNS: inserisci l'IP del tuo DNS globale.
- Convalida DNSSEC: deseleziona (poiché si tratta di un ambiente privato locale)
Fai clic su Salva.

Crea variabili di ambiente ACME

In questa sezione, creerai le seguenti variabili di ambiente per configurare il client Certbot. Modifica questi valori in base alle tue esigenze:

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

Registra il client Certbot

Successivamente, installi il client Certbot standard e lo registri con l'endpoint ACME privato di EJBCA. In questo modo viene stabilito l'account cliente attendibile necessario per eseguire operazioni automatiche sui certificati:

Installa certbot sulla tua workstation. Ad esempio, per macOS:
```
brew install certbot
```

Crea cartelle locali per la configurazione e i log:

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

Registra il client con l'endpoint della directory 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

Emetti un certificato utilizzando la verifica DNS

Infine, esegui una richiesta Certbot manuale ed esegui il deployment di una risorsa TXT DNS GDC temporanea per risolvere la verifica DNS-01. In questo modo, viene convalidata la proprietà del dominio di destinazione e viene attivata l'emissione automatica dei certificati:

Esegui il comando di verifica manuale:

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}

Il terminale si arresterà e mostrerà un valore di verifica. Output di esempio:

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.

Esegui il deployment del record TXT nel DNS globale con la stringa fornita da Certbot.

Attendi circa 30 secondi per la propagazione del DNS, torna al terminale Certbot e premi Invio.

Output di esempio:

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.

Verifica che il certificato sia stato scritto correttamente in ./certbot/config/live/test.${EJBCA_DNS_ZONE}/.

Implementazione di riferimento di Keyfactor EJBCA Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.