Implementação de referência do Keyfactor EJBCA

Visão geral

Este guia mostra como integrar o 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 certificadora altamente escalonável, robusta e em conformidade com o FIPS que permite que as organizações gerenciem a infraestrutura de chave pública (PKI) 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, as organizações que padronizaram a infraestrutura de PKI no Keyfactor EJBCA para cargas de trabalho atuais fora do GDC podem preferir usar a mesma arquitetura de CA e as mesmas políticas de gerenciamento consistentes para cargas de trabalho em execução nos ambientes do GDC com isolamento físico.

Neste guia, demonstramos como configurar a rede do GDC, o DNS interno e o cert-manager do Kubernetes para automatizar o gerenciamento do ciclo de vida de certificados (ACME) e oferecer suporte à emissão programática de alto volume usando um padrão de autoridade de registro (RA).

Suposições

Antes de prosseguir com este guia, verifique se as seguintes premissas foram atendidas:

  • 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, subordinada e de gerenciamento foram criadas na instância do EJBCA.
  • Os perfis de entidade final (EE) foram configurados (por exemplo, para certificados de servidor TLS).
  • Os certificados para os 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 instância do EJBCA.

Arquitetura

A arquitetura segue o modelo de autoridade certificadora externa, em que o servidor EJBCA e o módulo de segurança de hardware (HSM) de apoio 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 dispositivo de hardware ou software. A integração principal descrita neste guia exige apenas 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 de CA dentro de um HSM certificado CC EAL4+.
  • Cluster do Kubernetes padrão do GDC: o ambiente de computação que executa cargas de trabalho do cliente, o cert-manager e proxies de integração.
  • DNS interno do GDC: gerencia zonas de DNS particulares locais (usando o nome de domínio particular configurado nas variáveis de ambiente) usadas para resolver desafios de 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 externo do servidor EJBCA.
  • Registro particular do Harbor: hospeda imagens de contêiner espelhadas (como o emissor do cert-manager do EJBCA) para implantação com isolamento físico.

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 o detentor 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 fazer o download dos manifestos e das imagens de contêiner necessários. Se você estiver executando isso em uma máquina sem acesso à Internet, precisará conseguir esses recursos separadamente (por exemplo, usando docker save para exportar imagens de uma máquina conectada e docker load para importá-las) e fazer upload deles com segurança para seu ambiente antes de continuar.

Configurar aliases do kubectl

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

  • Crie um alias para a API de gerenciamento zonal (substitua MANAGEMENT_API_KUBECONFIG pelo caminho para o kubeconfig da API de gerenciamento):

    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 os papéis de administrador do cluster padrão do GDC e as credenciais do Container Registry local do Harbor:

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

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

2 Selecione um tipo de máquina apropriado 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 Depois que 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 definir as configurações de rede e infraestrutura do GDC. Isso garante que as cargas de trabalho do Kubernetes possam resolver o nome de domínio do host externo do EJBCA e rotear 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 para um nome de domínio local, permitindo que os serviços dentro do GDC se conectem usando um nome de host estável em vez de um endereço IP bruto:

  • Atribua o papel de Administrador do projeto de 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 ManagedDNSZone global:

    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 que aponta 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 definindo uma sub-rede personalizada e um gateway NAT para permitir que as cargas de trabalho do Kubernetes (como clientes do cert-manager e da autoridade de registro) encaminhem com segurança o tráfego de saída 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 correspondente 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 automatizados de certificados para seus serviços em contêineres.

Diagrama de integração do cert-manager 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 configure as vinculações de papéis 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 as restrições criptográficas (como algoritmos e períodos de validade) do certificado administrativo:

  • Abra a interface de admin do EJBCA e acesse Funções da AC > Perfis de certificado.
  • Clone o perfil ENDUSER e nomeie-o 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 uso
    • Pontos de distribuição de CRL: marque Usar.
    • Usar o ponto de distribuição de CRL definido pela CA: marque Usar.
    • Acesso às informações da autoridade: marque Usar.
    • Usar o localizador OCSP definido pela AC: 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, o que simplifica o processo de registro 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 defina as seguintes configuraçõ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, você registra a identidade administrativa usando a interface da autoridade de registro (RA) do EJBCA e extrai 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 AC
    • 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 Fazer o download do 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 de CA subordinada e raiz):

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

Configurar papéis e regras de acesso

Por fim, crie um papel administrativo no EJBCA e vincule-o 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 de admin do EJBCA, acesse Funções de 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 o papel 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 papel: 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: limpe Ver registro de auditoria.
  • Clique em Salvar.

Preparar o cluster do GDC

Para preparar o ambiente do GDC, autentique-se com seu cluster padrão do Kubernetes e armazene as credenciais administrativas extraídas do EJBCA nos secrets do Kubernetes, tornando-as acessíveis com segurança para os 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 da 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 registro particular do Harbor e implante o gráfico do Helm. Isso instancia o controlador personalizado necessário para converter as solicitações de certificado do Kubernetes em chamadas de API do EJBCA:

  • Crie um secret de extração de imagem 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

  • Espelhe a 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 as 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 do cert-manager do Kubernetes:

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

    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 ClusterIssuer global:

    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 de certificado padrão do Kubernetes para testar o fluxo completo do cert-manager e confirmar se o EJBCA assina e provisiona o certificado solicitado:

Crie um recurso de teste Certificate 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ê vai configurar o serviço ACME do EJBCA e usar os recursos de DNS interno do GDC para automatizar a emissão de certificados validados por domínio. Isso permite que 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 as respostas de desafio DNS-01 dentro do GDC:

  • Na interface de admin do EJBCA, acesse Configuração do sistema > Configuração do ACME.
  • 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 de DNS de validação de MPIC de resposta ao desafio: selecione dns-01.
    • Resolvedor de DNS: insira o IP do seu DNS global.
    • Validar DNSSEC: desmarque (já que este é um ambiente particular local)
  • Clique em Salvar.

Criar variáveis de ambiente ACME

Nesta seção, você vai criar as seguintes variáveis de ambiente para configurar o cliente do Certbot. Modifique esses 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 Certbot padrão e registre-o no endpoint ACME privado do EJBCA. Isso estabelece a conta de cliente confiável necessária para realizar operações de certificado automatizadas:

  • Instale o certbot na estação de trabalho. Por exemplo, para 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, você executa uma solicitação manual do Certbot e implanta um recurso temporário de TXT de DNS do GDC para resolver o desafio DNS-01. Isso valida sua propriedade do domínio de destino e aciona a emissão automatizada 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 exibir 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}/.