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 descrive l'integrazione di Keyfactor EJBCA Enterprise (deployato come appliance esterno) 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 a FIPS che consente alle organizzazioni di gestire l'infrastruttura a chiave pubblica (PKI) in ambienti eterogenei.

GDC con air gap include un servizio di autorità di certificazione integrato per la gestione automatizzata di chiavi e certificati all'interno del perimetro del cloud ospitato. Tuttavia, le organizzazioni che hanno standardizzato la propria infrastruttura PKI su Keyfactor EJBCA per i carichi di lavoro esistenti al di fuori di GDC potrebbero preferire sfruttare la stessa architettura CA e le stesse policy di gestione coerenti per i carichi di lavoro eseguiti all'interno dei propri ambienti GDC isolati.

Questa guida mostra come configurare il networking GDC, il DNS interno e Kubernetes cert-manager 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 soddisfatte le seguenti ipotesi:

Keyfactor EJBCA viene implementato come appliance software o hardware e per il servizio viene configurato un indirizzo IP stabile.
Sono state create autorità di certificazione (CA) radice, subordinate e di gestione nell'istanza EJBCA.
Sono stati configurati profili di entità finale (ad es. 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 quanto configurato nell'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 del GDC, ma sono accessibili dalla rete. Il server EJBCA può essere implementato 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: deployment esterno come appliance hardware o software Keyfactor, che ospita le CA (radice e subordinate) e genera tutto il materiale delle chiavi CA all'interno di un HSM con certificazione CC EAL4+.
Cluster Kubernetes standard GDC: l'ambiente di calcolo che esegue i carichi di lavoro dei clienti, cert-manager e i proxy di integrazione.
DNS interno GDC: gestisce le zone DNS private locali (utilizzando il nome di dominio privato configurato nelle variabili di ambiente) utilizzate per risolvere le sfide ACME DNS-01.
Gateway di uscita GDC: indirizza il traffico in uscita dai pod del cluster all'indirizzo IP del server EJBCA esterno.
Registro privato Harbor: ospita immagini container sottoposte a mirroring (come l'emittente EJBCA cert-manager) per il deployment air-gapped.

Prima di iniziare

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

Per prima cosa, 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 di rete: questa guida presuppone che venga eseguita da un nodo bastion che ha accesso alle API GDC con air gap e anche a internet per scaricare i manifest e le immagini dei 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.

Configurare gli alias kubectl

In questa sezione, crei alias della riga di comando pratici per le API globali e la gestione zonale di GDC:

Crea un alias per l'API di gestione zonale (sostituisci MANAGEMENT_API_KUBECONFIG con il percorso del file 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 file kubeconfig per l'API globale):
```
alias kg="kubectl --kubeconfig GLOBAL_API_KUBECONFIG"
```

Crea il cluster standard GDC

In questa sezione, esegui il deployment di un cluster Kubernetes standard all'interno di GDC e configura i ruoli di amministratore del cluster GDC standard e le credenziali del registro dei container Harbor locale:

1. Identifica i tipi di immagini di 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 di lavoro utilizzando l'API di gestione 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. 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 segreta.

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 sottostante e le impostazioni della rete. In questo modo, i tuoi carichi di lavoro Kubernetes possono risolvere il nome di dominio host EJBCA esterno e instradare correttamente le chiamate API in uscita al suo indirizzo IP.

Configurazione del DNS privato in GDC con air gap

Per stabilire la risoluzione del dominio, devi implementare una zona DNS privata e un insieme 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 di amministratore del progetto DNS gestito all'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 globale ManagedDNSZone:

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 puntando all'indirizzo IP dell'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 la rete in uscita GDC impostando una subnet personalizzata e un gateway NAT per consentire ai workload Kubernetes (come cert-manager e i client dell'autorità di registrazione) di instradare in modo sicuro il traffico in uscita al server EJBCA:

Assegna i ruoli di sviluppatore di rete a livello di progetto e 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, integri l'emittente cert-manager EJBCA personalizzata con il servizio cert-manager di GDC. In questo modo, puoi stabilire il provisioning, il rinnovo e la gestione del ciclo di vita automatici dei certificati per i tuoi servizi containerizzati.

Diagramma di integrazione di EJBCA cert-manager.

Configura EJBCA per l'emittente

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

Crea profilo del certificato amministratore

Inizia creando 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 la UI di amministrazione di EJBCA, vai a Funzioni CA > Profili certificato.
Clona il profilo ENDUSER e chiamalo 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
- Nome alternativo dell'emittente: deseleziona Usa
- Punti di distribuzione CRL: seleziona Usa
- Utilizza il punto di distribuzione CRL definito dalla CA: seleziona Utilizza.
- Accesso alle informazioni sull'autorità: seleziona Usa
- Utilizza il localizzatore OCSP definito dalla CA: seleziona Utilizza.
- Utilizza l'emittente CA definita dalla CA: seleziona Utilizza.
- CA disponibili: seleziona GDC Subordinate CA
Fai clic su Salva.

Crea profilo dell'entità finale dell'amministratore

Successivamente, crea un profilo di entità finale in EJBCA per definire i campi predefiniti e le assegnazioni di CA, il che semplifica la procedura di registrazione ed emissione del certificato amministrativo:

Vai a RA Functions (Funzioni RA) > End Entity Profiles (Profili entità finale).
Nella sezione 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 dei certificati disponibili: GDC ADMIN PROFILE
- CA predefinita: GDC Subordinate CA
- CA disponibili: GDC Subordinate CA
Fai clic su Salva.

Registra il certificato amministratore

Una volta creati 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.

Dividi 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, crea un ruolo amministrativo in EJBCA e lo associa al numero di serie del certificato cert-manager per assicurarti che l'emittente disponga solo del set minimo di autorizzazioni richieste per approvare e richiedere i certificati:

Nell'interfaccia utente amministrativa di EJBCA, vai a Funzioni RA > Cerca entità finali.
Cerca l'entità finale cert-manager e registra il relativo numero di serie del certificato.
Vai a Funzioni di sistema > Ruoli e regole di accesso e fai clic su 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.

Preparare il cluster GDC

Per preparare l'ambiente GDC, esegui l'autenticazione con il cluster Kubernetes standard e archivia le credenziali amministrative EJBCA estratte all'interno dei secret Kubernetes, rendendole accessibili in modo sicuro ai pod emittenti 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 personalizzata:
```
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 registro Harbor privato ed esegui il deployment del grafico Helm. Questo crea un'istanza del controller personalizzato necessario per tradurre le richieste di certificati 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 dell'emittente cert-manager EJBCA ufficiale 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

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 e implementa una risorsa globale ClusterIssuer, 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 globale ClusterIssuer:

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, devi eseguire il deployment di una risorsa certificato Kubernetes standard per testare il flusso end-to-end di cert-manager e confermare che EJBCA firma e fornisce correttamente il certificato richiesto:

Crea una risorsa di test Certificate per verificare l'integrazione 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, configuri il servizio ACME di EJBCA e utilizzi le risorse DNS interne di GDC per automatizzare l'emissione di certificati con convalida del dominio. Ciò consente ai client standard cert-manager o Certbot di richiedere certificati utilizzando protocolli ACME automatizzati standard.

Configura EJBCA per ACME

Per preparare il server, devi abilitare il servizio ACME all'interno di EJBCA e configurare un alias ACME con un resolver DNS dedicato. In questo modo, il server EJBCA viene preparato per elaborare e convalidare le risposte alla sfida DNS-01 all'interno di GDC:

Nell'interfaccia utente di amministrazione di EJBCA, vai a Configurazione del sistema > Configurazione ACME.
Fai clic su Aggiungi e configura quanto segue:
- Nome: default
- Profilo dell'entità finale: GDC TLS SERVER EE PROFILE
- Emissione di certificati con caratteri jolly consentita: seleziona
- Tipi di verifica dell'identificatore DNS per la convalida MPIC della risposta alla sfida: Seleziona dns-01
- Resolver DNS: inserisci l'IP del tuo DNS globale.
- Validate DNSSEC (Convalida DNSSEC): chiaro (poiché si tratta di un ambiente privato locale)
Fai clic su Salva.

Crea variabili di ambiente ACME

In questa sezione, crea le seguenti variabili di ambiente per configurare il client Certbot. Modifica questi valori in base alle 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, installa il client Certbot standard e registralo con l'endpoint ACME privato di EJBCA. In questo modo viene stabilito l'account client attendibile necessario per eseguire operazioni automatizzate sui certificati:

Installa certbot sulla 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 EJBCA ACME:

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

Emettere un certificato utilizzando la verifica DNS

Infine, esegui una richiesta Certbot manuale e implementa 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 del certificato:

Esegui il comando per la 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 fermerà 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.

Implementa il record TXT nel tuo 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.