Implementação de referência do Keyfactor EJBCA

Visão geral

Este guia mostra a integração do Keyfactor EJBCA Enterprise (implantado como um dispositivo externo) como uma autoridade certificadora (AC) de terceiros para o Google Distributed Cloud (GDC) com isolamento físico.

O Keyfactor EJBCA Enterprise é uma plataforma de autoridade de certificação altamente escalonável, robusta e compatível com FIPS que permite às organizações gerenciar a infraestrutura de chave pública (ICP) em ambientes heterogêneos.

O GDC com isolamento físico inclui um serviço de autoridade certificadora integrado para gerenciamento automatizado de chaves e certificados dentro do limite da nuvem hospedada. No entanto, organizações que padronizaram a infraestrutura de PKI no Keyfactor EJBCA para cargas de trabalho fora do GDC podem preferir usar a mesma arquitetura de CA e políticas de gerenciamento consistentes para cargas de trabalho executadas em ambientes do GDC isolados.

Este guia demonstra como configurar a rede do GDC, o DNS interno e o cert-manager do Kubernetes para automatizar o gerenciamento do ciclo de vida do certificado (ACME) e oferecer suporte à emissão programática de alto volume usando um padrão de autoridade de registro (RA, na sigla em inglês).

Suposições

Antes de seguir este guia, verifique se as seguintes proposições são verdadeiras:

  • O Keyfactor EJBCA é implantado como um appliance de software ou de hardware, e um endereço IP estável é configurado para o serviço.
  • As autoridades certificadoras (CAs) raiz, subordinadas e de gerenciamento foram criadas na instância do EJBCA.
  • Os perfis de entidade final (EE, na sigla em inglês) foram configurados (por exemplo, para certificados de servidor TLS).
  • Os certificados dos usuários da CA administrativa foram baixados.
  • Os protocolos necessários (como ACME) estão ativados na instância do EJBCA.
  • Os algoritmos de assinatura RSA são usados neste guia. É possível mudar o algoritmo de assinatura com base nos seus requisitos específicos ou no que está configurado na sua instância do EJBCA.

Arquitetura

A arquitetura segue o modelo de autoridade de certificação externa, em que o servidor EJBCA e o módulo de segurança de hardware (HSM) de suporte são hospedados externamente fora dos limites físicos do GDC, mas são acessíveis pela rede. O servidor EJBCA pode ser implantado externamente como um appliance de hardware ou software. A integração principal descrita neste guia só exige que o servidor EJBCA externo seja acessível usando um endereço IP estável.

Diagrama de arquitetura do Keyfactor EJBCA.

Os principais componentes dessa arquitetura incluem:

  • EJBCA Enterprise Server: implantado externamente como um dispositivo de hardware ou software da Keyfactor, que abriga as CAs (raiz e subordinada) e gera todo o material de chave da CA em um HSM certificado CC EAL4+.
  • Cluster padrão do Kubernetes do GDC: o ambiente de computação que executa cargas de trabalho do cliente, cert-manager e proxies de integração.
  • DNS interno do GDC: gerencia zonas DNS particulares locais (usando o nome de domínio particular configurado nas variáveis de ambiente) usadas para resolver desafios DNS-01 do ACME.
  • Gateway de saída do GDC: direciona o tráfego de saída dos pods do cluster para o endereço IP do servidor EJBCA externo.
  • Registro privado do Harbor: hospeda imagens de contêiner espelhadas (como o emissor do gerenciador de certificados EJBCA) para implantação isolada.

Antes de começar

Verifique se o ambiente do GDC atende aos seguintes requisitos antes de iniciar a integração:

  • Primeiro, crie um projeto que vai servir como contêiner de todos os recursos gerados ao longo deste guia.

  • Configure as variáveis de ambiente que serão referenciadas ao longo deste guia. Modifique esses valores conforme necessário para corresponder ao seu ambiente específico:

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

  • Observação sobre a rede: este guia pressupõe que ele está sendo executado em um nó bastion que tem acesso às APIs do GDC com isolamento físico e também à Internet para baixar os manifestos e as imagens de contêiner necessários. Se você estiver executando isso em uma máquina sem acesso à Internet, será necessário obter esses recursos separadamente. Por exemplo, use docker save para exportar imagens de uma máquina conectada e docker load para importá-las. Depois, faça upload delas com segurança para seu ambiente antes de continuar.

Configurar aliases do kubectl

Nesta seção, você vai criar aliases convenientes de linha de comando para o gerenciamento zonal e as APIs globais do GDC:

  • Crie um alias para a API zonal management. Substitua MANAGEMENT_API_KUBECONFIG pelo caminho para o kubeconfig da API management:

    alias km="kubectl --kubeconfig MANAGEMENT_API_KUBECONFIG"

  • Crie um alias para a API global. Substitua GLOBAL_API_KUBECONFIG pelo caminho para o kubeconfig da API global:

    alias kg="kubectl --kubeconfig GLOBAL_API_KUBECONFIG"

Criar o cluster padrão do GDC

Nesta seção, você vai implantar um cluster padrão do Kubernetes no GDC e configurar as funções de administrador do cluster padrão do GDC e as credenciais locais do registro de contêiner do Harbor:

1 Identifique os tipos de imagens máquina virtual disponíveis executando:

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

2 Selecione um tipo de máquina adequado para os nós de trabalho do cluster:

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

3. Crie um cluster padrão com dois nós de trabalho usando a API de gerenciamento zonal:

```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 o cluster estiver pronto, recupere as credenciais dele:

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

5 Atribua funções de administrador de cluster padrão do GDC ao usuário do 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 Crie uma instância e um projeto do Harbor no GDC para hospedar as imagens de contêiner espelhadas:

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

7 Crie uma conta de robô do Harbor e registre o nome de usuário e a chave secreta dela.

8 Faça a autenticação com sua instância do 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.

Configuração de infraestrutura e rede

Nesta seção, você vai configurar a infraestrutura e as configurações de rede do GDC. Isso garante que as cargas de trabalho do Kubernetes possam resolver o nome de domínio do host EJBCA externo e encaminhar as chamadas de API de saída para o endereço IP dele.

Configuração de DNS particular no GDC com isolamento físico

Para estabelecer a resolução de domínio, implante uma zona de DNS particular e um conjunto de registros para mapear o servidor EJBCA externo a um nome de domínio local, permitindo que os serviços dentro do GDC se conectem usando um nome do host estável em vez de um endereço IP bruto:

  • Atribua a função de administrador do projeto do DNS gerenciado ao seu usuário:

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

  • Implante o recurso global 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

  • Implante o ResourceRecordSet apontando para o endereço IP do 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

Configuração do gateway NAT de saída

Em seguida, configure a rede de saída do GDC criando uma sub-rede personalizada e um gateway NAT para permitir que as cargas de trabalho do Kubernetes (como o cert-manager e os clientes da autoridade de registro) roteiem o tráfego de saída com segurança para o servidor EJBCA:

  • Atribua papéis de desenvolvedor de rede no nível do projeto e da organização:

    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

  • Crie a sub-rede de saída:

    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

  • Crie o CloudNATGateway que corresponde ao seletor de emissor do 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

Integração do cert-manager do Kubernetes

Nesta seção, você vai integrar o emissor personalizado do cert-manager do EJBCA ao serviço cert-manager do GDC. Isso permite estabelecer o provisionamento, a renovação e o gerenciamento do ciclo de vida de certificados automatizados para seus serviços contêinerizados.

Diagrama de integração do gerenciador de certificados do EJBCA.

Configurar o EJBCA para o emissor

Para integrar o emissor, configure os perfis necessários, registre a credencial do cliente de administração e defina as vinculações de função no servidor EJBCA. Isso estabelece um canal administrativo seguro que permite que o cert-manager se autentique e solicite certificados do EJBCA.

Criar perfil de certificado de administrador

Comece estabelecendo um perfil de certificado no EJBCA para definir as propriedades técnicas e restrições criptográficas (como algoritmos e períodos de validade) do certificado administrativo:

  • Abra a interface de administrador do EJBCA, navegue até Funções da CA > Perfis de certificado.
  • Clone o perfil ENDUSER e nomeie como GDC ADMIN PROFILE.
  • Edite o GDC ADMIN PROFILE e defina as seguintes configurações:
    • Algoritmos de chave disponíveis: RSA
    • Tamanhos de bits disponíveis: 2048, 3072, 4096
    • Algoritmo de assinatura: SHA512WithRSA
    • Validade: 200d
    • Nome alternativo do emissor: limpar Use
    • Pontos de distribuição de CRL: marque Usar.
    • Usar ponto de distribuição da CRL definido pela CA: marque Usar
    • Acesso às informações da autoridade: marque Uso
    • Usar localizador OCSP definido pela CA: marque Usar.
    • Usar o emissor de CA definido pela CA: marque Usar.
    • CAs disponíveis: selecione GDC Subordinate CA
  • Clique em Salvar.

Criar perfil de entidade final do administrador

Em seguida, crie um perfil de entidade final no EJBCA para definir campos padrão e atribuições de CA que simplificam o processo de inscrição e emissão do certificado administrativo:

  • Acesse Funções de RA > Perfis de entidade final.
  • Em Adicionar perfil de entidade final, insira GDC ADMIN EE PROFILE e clique em Adicionar perfil.
  • Edite o perfil e configure as seguintes opções:
    • Perfil de certificado padrão: GDC ADMIN PROFILE
    • Perfis de certificado disponíveis: GDC ADMIN PROFILE
    • AC padrão: GDC Subordinate CA
    • CAs disponíveis: GDC Subordinate CA
  • Clique em Salvar.

Registrar certificado de administrador

Com os perfis estabelecidos, registre a identidade administrativa usando a interface da autoridade de registro (RA) do EJBCA e extraia a chave privada, o certificado público e a cadeia de confiança para gerar os arquivos de credenciais impressas necessários para autenticar o cert-manager:

  • Acesse a guia RA Web.
  • Clique em Fazer nova solicitação e configure:
    • Tipo de certificado: GDC ADMIN EE PROFILE
    • Geração de par de chaves: pela CA
    • Algoritmo de chave: RSA de 4.096 bits
    • Nome comum (CN): cert-manager
    • Nome de usuário: cert-manager
    • Código de inscrição: abcd
  • Clique em Baixar PEM e salve como cert-manager.pem.

  • Divida os arquivos PEM em três arquivos:

    • client.key (a chave secreta):

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

    • client.crt (o certificado público):

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

    • ca.crt (a cadeia de confiança com os certificados da CA subordinada e raiz):

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

Configurar funções e regras de acesso

Por fim, crie uma função administrativa no EJBCA e vincule-a ao número de série do certificado do cert-manager para garantir que o emissor tenha apenas o conjunto mínimo de permissões necessárias para aprovar e solicitar certificados:

  • Na interface administrativa do EJBCA, navegue até Funções da RA > Pesquisar entidades finais.
  • Pesquise a entidade final cert-manager e registre o número de série do certificado.
  • Acesse Funções do sistema > Funções e regras de acesso e clique em Adicionar.
  • Nomeie a função como cert-manager e adicione um novo membro usando o número de série que você registrou.
  • Clique em Editar regras de acesso e configure os seguintes privilégios:
    • Modelo de função: administradores de RA
    • CAs autorizadas: GDC Subordinate CA
    • Regras de entidade final: aprovar, criar e editar entidades finais
    • Perfis de entidade final: GDC TLS SERVER EE PROFILE
    • Outras regras: desmarque Ver registro de auditoria.
  • Clique em Salvar.

Preparar o cluster do GDC

Para preparar o ambiente do GDC, faça a autenticação com seu cluster padrão do Kubernetes e armazene as credenciais administrativas extraídas do EJBCA em secrets do Kubernetes, tornando-as acessíveis com segurança aos pods do emissor do cert-manager:

  • Recupere as credenciais do cluster padrão:

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

  • Crie o namespace de destino para o emissor personalizado:

    kubectl create ns ejbca-issuer-system

  • Implante o secret de autenticação TLS:

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

  • Implante o secret da cadeia de confiança do EJBCA:

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

Instalar o emissor do EJBCA

Para configurar a implantação, espelhe a imagem do contêiner do emissor do cert-manager do EJBCA no seu registro particular do Harbor e implante o gráfico do Helm. Isso instancia o controlador personalizado necessário para traduzir solicitações de certificado do Kubernetes em chamadas de API do EJBCA:

  • Crie um secret de extração de imagens do Harbor no namespace do emissor:

    # 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

  • Faça o espelhamento da imagem oficial do emissor do cert-manager do EJBCA para o 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

  • Adicione o repositório do Helm e faça o download do gráfico:

    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

  • Implante o gráfico do Helm usando o repositório de imagens espelhado:

    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

Criar o recurso do emissor

Em seguida, estabeleça permissões de RBAC do GDC e implante um recurso global ClusterIssuer, que registra o servidor EJBCA como uma fonte de assinatura confiável no framework cert-manager do Kubernetes:

  • Configure as permissões do RBAC para permitir que o controlador cert-manager do GDC use o emissor EJBCA personalizado:

    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

  • Implante o recurso global 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

  • Verifique o status do emissor:

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

    A saída vai mostrar:

    NAME                  STATUS
clusterissuer-ejbca   Success

Solicitar um certificado

Para verificar a integração, implante um recurso padrão de certificado do Kubernetes para testar o fluxo completo do cert-manager e confirmar que o EJBCA assina e provisiona o certificado solicitado:

Crie um recurso Certificate de teste para verificar se a integração foi bem-sucedida:

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

Verifique se o certificado foi criado e está pronto:

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

A saída vai mostrar:

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

ACME automatizado com desafios DNS-01

Nesta seção, você configura o serviço ACME do EJBCA e usa recursos internos de DNS do GDC para automatizar a emissão de certificados validados por domínio. Isso permite que os clientes padrão do cert-manager ou do Certbot solicitem certificados usando protocolos ACME automatizados padrão.

Configurar o EJBCA para ACME

Para preparar o servidor, ative o serviço ACME no EJBCA e configure um alias ACME com um resolvedor de DNS dedicado. Isso prepara o servidor EJBCA para processar e validar respostas de desafio DNS-01 no GDC:

  • Na interface administrativa do EJBCA, acesse System Configuration > ACME Configuration.
  • Clique em Adicionar e configure o seguinte:
    • Nome: default
    • Perfil da entidade final: GDC TLS SERVER EE PROFILE
    • Emissão de certificado curinga permitida: marque
    • Tipos de desafio de identificador DNS de validação MPIC de resposta a desafio: selecione dns-01
    • Resolvedor de DNS: insira o IP do seu DNS global.
    • Validar DNSSEC: limpo (já que este é um ambiente particular local)
  • Clique em Salvar.

Criar variáveis de ambiente do ACME

Nesta seção, você vai criar as seguintes variáveis de ambiente para configurar o cliente Certbot. Modifique estes valores conforme necessário:

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

Registrar o cliente do Certbot

Em seguida, instale o cliente padrão do Certbot e registre-o com o endpoint ACME privado do EJBCA. Isso estabelece a conta de cliente confiável necessária para realizar operações automatizadas de certificado:

  • Instale o certbot na sua estação de trabalho. Por exemplo, no macOS:

    brew install certbot

  • Crie pastas locais para configuração e registros:

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

  • Registre o cliente com o endpoint do diretório ACME do 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

Emitir um certificado usando o desafio de DNS

Por fim, execute uma solicitação manual do Certbot e implante um recurso TXT DNS do GDC temporário para resolver o desafio DNS-01. Isso valida sua propriedade do domínio de destino e aciona a emissão automática de certificados:

  • Execute o comando de desafio manual:

    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}

    O terminal vai parar e mostrar um valor de desafio. Exemplo de saída:

    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.

  • Implante o registro TXT no DNS global com a string fornecida pelo Certbot.

  • Aguarde cerca de 30 segundos para a propagação do DNS, volte ao terminal do Certbot e pressione Enter.

    Exemplo de saída:

    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.

  • Verifique se o certificado foi gravado em ./certbot/config/live/test.${EJBCA_DNS_ZONE}/.