Keyfactor EJBCA 參考實作

總覽

本指南逐步說明如何整合 Keyfactor EJBCA Enterprise (部署為外部設備)，做為 Google Distributed Cloud (GDC) 實體隔離方案的第三方憑證授權單位 (CA)。

Keyfactor EJBCA Enterprise 是高度可擴充、穩健且符合 FIPS 標準的憑證授權單位平台，可讓組織跨異質環境管理公用金鑰基礎架構 (PKI)。

GDC 實體隔離方案包含內建的憑證授權單位服務，可在託管雲端邊界內自動管理金鑰和憑證。不過，如果組織已在 Keyfactor EJBCA 上標準化 PKI 基礎架構，用於 GDC 以外的現有工作負載，則可能偏好在實體隔離的 GDC 環境中，對執行的工作負載採用相同且一致的 CA 架構和管理政策。

本指南說明如何設定 GDC 網路、內部 DNS 和 Kubernetes cert-manager，以自動管理憑證生命週期 (ACME)，並使用註冊機構 (RA) 模式支援大量程式輔助核發。

假設

請先確認符合下列假設，再按照本指南操作：

  • Keyfactor EJBCA 會部署為軟體或硬體設備，並為服務設定穩定的 IP 位址。
  • 根、從屬和管理憑證授權單位 (CA) 已在 EJBCA 執行個體中建立。
  • 已設定終端實體 (EE) 設定檔 (例如 TLS 伺服器憑證)。
  • 已下載管理員 CA 使用者的憑證。
  • EJBCA 執行個體已啟用必要通訊協定 (例如 ACME)。
  • 本指南使用 RSA 簽署演算法。您可以根據特定需求或 EJBCA 執行個體中的設定，變更簽署演算法。

架構

這個架構採用外部憑證授權單位模型，EJBCA 伺服器及其支援的硬體安全模組 (HSM) 託管於實體 GDC 邊界外，但可透過網路存取。EJBCA 伺服器可以部署在外部，做為硬體或軟體設備。本指南所述的核心整合，只需要外部 EJBCA 伺服器可透過穩定的 IP 位址連線即可。

Keyfactor EJBCA 架構圖。

這個架構的主要元件包括：

  • EJBCA Enterprise Server：以 Keyfactor 硬體設備或軟體設備的形式部署於外部，用於存放 CA (根和下層)，並在 CC EAL4+ 認證的 HSM 內產生所有 CA 金鑰內容。
  • GDC 標準 Kubernetes 叢集：執行客戶工作負載、cert-manager 和整合 Proxy 的運算環境。
  • GDC 內部 DNS：管理本機私人 DNS 區域 (使用環境變數中設定的私人網域名稱)，用於解析 ACME DNS-01 驗證。
  • GDC 輸出閘道：將叢集 Pod 的傳出流量導向外部 EJBCA 伺服器 IP 位址。
  • Harbor 私人登錄檔：託管鏡像容器映像檔 (例如 EJBCA cert-manager 核發者)，用於實體隔離部署。

事前準備

開始整合前，請確認 GDC 環境符合下列需求：

  • 首先，請建立專案，用於存放本指南中產生的所有資源。

  • 設定本指南中會參照的環境變數。請視需要修改這些值，以符合您的特定環境：

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

  • 網路注意事項：本指南假設您是從堡壘節點執行，該節點可存取 GDC 實體隔離方案 API，並可連上網際網路下載必要的資訊清單和容器映像檔。如果是在沒有網路連線能力的機器上執行這項操作，您必須另外取得這些資產 (例如使用 docker save 從連線的機器匯出映像檔，並使用 docker load 匯入)，並安全地上傳至環境，再繼續操作。

設定 kubectl 別名

在本節中，您將為 GDC 的可用區管理和全域 API 建立方便的指令列別名：

  • 為可用區管理 API 建立別名 (將 MANAGEMENT_API_KUBECONFIG 替換為管理 API 的 kubeconfig 路徑)：

    alias km="kubectl --kubeconfig MANAGEMENT_API_KUBECONFIG"

  • 為全域 API 建立別名 (將 GLOBAL_API_KUBECONFIG 替換為全域 API 的 kubeconfig 路徑)：

    alias kg="kubectl --kubeconfig GLOBAL_API_KUBECONFIG"

建立 GDC 標準叢集

在本節中，您將在 GDC 部署標準 Kubernetes 叢集，並設定 GDC 標準叢集管理員角色和本機 Harbor Container Registry 憑證：

1 執行下列指令，找出可用的虛擬機器映像檔類型：

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

2 為叢集 worker 節點選取合適的機器類型：

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

3 使用可用區管理 API 建立具有兩個 worker 節點的標準叢集：

```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 叢集準備就緒後，請擷取其憑證：

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

5 將 GDC 標準叢集管理員角色指派給 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 在 GDC 中建立 Harbor 執行個體和 Harbor 專案，用於託管鏡像容器映像檔：

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

7 建立 Harbor 機器人帳戶，並記錄其使用者名稱和密鑰。

8 使用 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.

基礎架構和網路設定

在本節中，您將設定基礎 GDC 基礎架構和網路設定。這樣一來，Kubernetes 工作負載就能解析外部 EJBCA 主機網域名稱，並成功將傳出 API 呼叫轉送至其 IP 位址。

在 GDC 實體隔離方案中設定私人 DNS

如要建立網域解析，請部署私人 DNS 區域和記錄集，將外部 EJBCA 伺服器對應至本機網域名稱，讓 GDC 內部的服務使用穩定的主機名稱連線，而非原始 IP 位址：

  • 將「代管 DNS 專案管理員」角色指派給使用者：

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

  • 部署全域 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

  • 部署指向 EJBCA 設備 IP 位址的 ResourceRecordSet：

    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

設定傳出 NAT 閘道

接著，您要設定 GDC 輸出網路，方法是設定自訂子網路和網路位址轉譯 (NAT) 閘道，允許 Kubernetes 工作負載 (例如 cert-manager 和註冊機構用戶端) 安全地將傳出流量轉送至 EJBCA 伺服器：

  • 指派專案和組織層級的網路開發人員角色：

    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

  • 建立輸出子網路：

    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

  • 建立與 cert-manager 核發者選取器相符的 CloudNATGateway：

    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

Kubernetes cert-manager 整合

在本節中，您會將自訂 EJBCA cert-manager 核發者與 GDC 的 cert-manager 服務整合。這樣一來，您就能為容器化服務建立自動化憑證佈建、更新和生命週期管理機制。

EJBCA cert-manager 整合圖表。

為核發者設定 EJBCA

如要整合核發者，您必須設定必要的設定檔、註冊管理用戶端憑證，並在 EJBCA 伺服器中設定角色繫結。這會建立安全的管理管道，讓 cert-manager 向 EJBCA 驗證身分並要求憑證。

建立管理員憑證設定檔

首先，您要在 EJBCA 中建立憑證設定檔，定義管理憑證的技術屬性和加密編譯限制 (例如演算法和有效期限)：

  • 開啟 EJBCA 管理員 UI，依序前往「CA Functions」>「Certificate Profiles」。
  • 複製 ENDUSER 設定檔，並命名為 GDC ADMIN PROFILE。
  • 編輯 GDC ADMIN PROFILE 並進行下列設定：
    • 可用的金鑰演算法：RSA
    • 可用的位元長度：2048、3072、4096
    • Signature Algorithm：SHA512WithRSA
    • 有效性：200d
    • 核發者替代名稱：清除「Use」
    • CRL Distribution Points：勾選「Use」
    • 使用 CA 定義的 CRL 發布點：勾選「使用」
    • Authority Information Access：勾選「Use」
    • 使用 CA 定義的 OCSP 定位器：勾選「使用」
    • 使用 CA 定義的 CA 核發者：勾選「使用」
    • 可用的 CA：選取 GDC Subordinate CA
  • 按一下「儲存」。

建立管理員終端實體設定檔

接著，您要在 EJBCA 中建立終端實體設定檔，定義預設欄位和 CA 指派作業，簡化註冊及核發管理憑證的程序：

  • 依序前往「RA Functions」>「End Entity Profiles」。
  • 在「Add End Entity Profile」(新增終端實體設定檔) 下方，輸入 GDC ADMIN EE PROFILE，然後按一下「Add Profile」(新增設定檔)。
  • 編輯設定檔並調整下列設定：
    • 預設憑證設定檔：GDC ADMIN PROFILE
    • 可用的憑證設定檔：GDC ADMIN PROFILE
    • 預設 CA：GDC Subordinate CA
    • 可用的 CA：GDC Subordinate CA
  • 按一下「儲存」。

註冊管理員憑證

建立設定檔後，請使用 EJBCA 註冊機構 (RA) 介面註冊管理身分，並擷取私密金鑰、公開憑證和信任鏈，產生驗證 cert-manager 所需的實體憑證檔案：

  • 前往「RA Web」分頁。
  • 按一下「Make New Request」，然後設定下列項目：
    • 憑證類型：GDC ADMIN EE PROFILE
    • 金鑰組產生：由 CA 產生
    • 金鑰演算法：RSA 4096 位元
    • 一般名稱 (CN)：cert-manager
    • 使用者名稱：cert-manager
    • 註冊代碼：abcd
  • 點選「Download PEM」，並將檔案儲存為 cert-manager.pem。

  • 將 PEM 檔案分割成三個檔案：

    • client.key (密鑰)：

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

    • client.crt (公開憑證)：

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

    • ca.crt (包含從屬和根 CA 憑證的信任鏈)：

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

設定角色和存取規則

最後，您會在 EJBCA 中建立管理角色，並將其繫結至 cert-manager 憑證序號，確保核發者僅具備核准及要求憑證所需的最低權限：

  • 在 EJBCA 管理員 UI 中，依序前往「RA Functions」(RA 函式) >「Search End Entities」(搜尋終端實體)。
  • 搜尋 cert-manager 終端實體，並記錄其憑證序號。
  • 依序前往「System Functions」(系統函式) >「Roles and Access Rules」(角色和存取規則)，然後按一下「Add」(新增)。
  • 將角色命名為 cert-manager，並使用您記錄的序號新增成員。
  • 按一下「編輯存取規則」，然後設定下列權限：
    • 角色範本：RA 管理員
    • 授權 CA：GDC Subordinate CA
    • 終端實體規則：核准、建立及編輯終端實體
    • 終端實體設定檔：GDC TLS SERVER EE PROFILE
    • 其他規則：清除「查看稽核記錄」
  • 按一下「儲存」。

準備 GDC 叢集

如要準備 GDC 環境，請使用標準 Kubernetes 叢集進行驗證，並將擷取的 EJBCA 管理憑證儲存在 Kubernetes Secret 中，讓 cert-manager 核發者 Pod 能安全存取這些憑證：

  • 擷取標準叢集憑證：

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

  • 為自訂核發者建立目標命名空間：

    kubectl create ns ejbca-issuer-system

  • 部署 TLS 驗證 Secret：

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

  • 部署 EJBCA 信任鏈結 Secret：

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

安裝 EJBCA 核發者

如要設定部署作業，請將 EJBCA cert-manager 核發者容器映像檔，鏡像至私人 Harbor 登錄檔，並部署 Helm 圖表。這會例項化自訂控制器，用於將 Kubernetes 憑證要求轉譯為 EJBCA API 呼叫：

  • 在核發者的命名空間中，建立 Harbor 映像檔提取密鑰：

    # 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

  • 將官方 EJBCA cert-manager 核發者映像檔鏡像至 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

  • 新增 Helm 存放區並下載圖表：

    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

  • 使用鏡像映像檔存放區部署 Helm 資訊套件：

    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

建立核發者資源

接著，您將建立 GDC RBAC 權限，並部署全域 ClusterIssuer 資源，將 EJBCA 伺服器註冊為 Kubernetes cert-manager 架構中可信任的簽署來源：

  • 設定 RBAC 權限，允許 GDC 的 cert-manager 控制器使用自訂 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

  • 部署全域 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

  • 驗證核發者狀態：

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

    輸出內容應如下所示：

    NAME                  STATUS
clusterissuer-ejbca   Success

要求取得憑證

如要驗證整合，請部署標準 Kubernetes 憑證資源，測試端對端 cert-manager 流程，並確認 EJBCA 成功簽署及佈建要求的憑證：

建立測試 Certificate 資源，確認整合成功：

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

確認憑證已建立並準備就緒：

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

輸出內容應如下所示：

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

自動化 ACME 與 DNS-01 驗證

在本節中，您將設定 EJBCA 的 ACME 服務，並利用 GDC 內部 DNS 資源，自動核發網域驗證憑證。這樣一來，標準 cert-manager 或 Certbot 用戶端就能使用標準自動化 ACME 通訊協定要求憑證。

設定 EJBCA 的 ACME

如要準備伺服器，請在 EJBCA 中啟用 ACME 服務，並使用專屬 DNS 解析器設定 ACME 別名。這會準備 EJBCA 伺服器，以便在 GDC 內處理及驗證 DNS-01 驗證回應：

  • 在 EJBCA 管理員 UI 中，依序前往「System Configuration」(系統設定) >「ACME Configuration」(ACME 設定)。
  • 按一下「Add」(新增)，然後設定下列項目：
    • Name (名稱)：default
    • 終端實體設定檔：GDC TLS SERVER EE PROFILE
    • 萬用字元憑證核發已允許：勾選
    • Challenge Response MPIC Validation DNS identifier challenge types: 選取 dns-01
    • DNS 解析器：輸入全域 DNS 的 IP。
    • Validate DNSSEC：清除 (因為這是本機私人環境)
  • 按一下「儲存」。

建立 ACME 環境變數

在本節中，您將建立下列環境變數，用於設定 Certbot 用戶端。視需要修改下列值：

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

註冊 Certbot 用戶端

接著，您將安裝標準 Certbot 用戶端，並向 EJBCA 的私人 ACME 端點註冊。這會建立執行自動化憑證作業所需的信任用戶端帳戶：

  • 在工作站上安裝 certbot。例如，macOS：

    brew install certbot

  • 建立設定和記錄檔的本機資料夾：

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

  • 使用 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

使用 DNS 驗證核發憑證

最後，您會執行手動 Certbot 要求，並部署暫時性 GDC DNS TXT 資源，以解決 DNS-01 驗證問題。這會驗證您對目標網域的擁有權，並觸發自動核發憑證：

  • 執行手動驗證指令：

    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}

    終端機會停止並顯示驗證值。輸出內容範例：

    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.

  • 使用 Certbot 提供的字串，將 TXT 記錄部署至全域 DNS。

  • 等待約 30 秒，讓 DNS 傳播，然後返回 Certbot 終端機，並按下 Enter 鍵。

    輸出內容範例：

    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.

  • 確認憑證已成功寫入 ./certbot/config/live/test.${EJBCA_DNS_ZONE}/。