Keyfactor EJBCA 參考實作

總覽

本指南逐步說明如何整合 Keyfactor EJBCA Enterprise (部署為外部裝置)，做為 Google Distributed Cloud (GDC) 氣隙環境的第三方憑證授權單位 (CA)。

Keyfactor EJBCA Enterprise 是符合 FIPS 標準的強大憑證授權單位平台，具備高度擴充性， 可協助機構管理異質環境中的公用金鑰基礎架構 (PKI)。

GDC air-gapped 內含內建的憑證授權單位服務，可在代管雲端邊界內自動管理金鑰和憑證。不過，如果機構已針對 GDC 以外的現有工作負載，將 PKI 基礎架構標準化為 Keyfactor EJBCA，可能就會偏好對在無網路連線 GDC 環境中執行的工作負載，採用相同的 CA 架構和管理政策。

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

假設

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

  • Keyfactor EJBCA 部署為軟體或硬體裝置，且服務已設定穩定的 IP 位址。
  • 已在 EJBCA 執行個體中建立根、從屬和管理憑證授權單位 (CA)。
  • 已設定終端實體 (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 Standard Kubernetes 叢集：執行客戶工作負載、cert-manager 和整合 Proxy 的運算環境。
  • GDC 內部 DNS：管理用於解析 ACME DNS-01 驗證的本機私人 DNS 區域 (使用環境變數中設定的私人網域名稱)。
  • GDC 輸出閘道：將叢集 Pod 的輸出流量導向外部 EJBCA 伺服器 IP 位址。
  • Harbor 私人登錄檔：託管鏡像容器映像檔 (例如 EJBCA 憑證管理工具簽發者)，用於無網路連線部署作業。

事前準備

開始整合前，請確認 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 容器登錄憑證：

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

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

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

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

3. 使用可用區管理 API 建立含有兩個工作站節點的標準叢集：

```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

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

    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 閘道

接著，請設定自訂子網路和 NAT 閘道，允許 Kubernetes 工作負載 (例如 cert-manager 和註冊授權單位用戶端) 安全地將輸出流量路由至 EJBCA 伺服器，藉此設定 GDC 輸出網路：

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

    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

  • 建立 CloudNATGateway，與 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

整合 Kubernetes cert-manager

在本節中，您會將自訂 EJBCA cert-manager 簽發機構與 GDC 的 cert-manager 服務整合。這項功能可讓您為容器化服務建立自動憑證佈建、更新和生命週期管理機制。

EJBCA cert-manager 整合圖。

為簽發者設定 EJBCA

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

建立管理員憑證設定檔

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

  • 開啟 EJBCA 管理員使用者介面，然後依序前往「CA Functions」 >「Certificate Profiles」。
  • 複製 ENDUSER 設定檔，並命名為 GDC ADMIN PROFILE。
  • 編輯 GDC ADMIN PROFILE 並設定下列項目：
    • 可用的金鑰演算法：RSA
    • 可用位元長度：2048、3072、4096
    • 簽名演算法：SHA512WithRSA
    • 有效性：200d
    • 發卡機構替代名稱：清除「使用」
    • CRL 發布點：勾選「使用」
    • 使用 CA 定義的 CRL 發布點：勾選「使用」
    • 授權單位資訊存取權：勾選「使用」
    • 使用 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」分頁。
  • 按一下「提出新要求」，然後設定：
    • 認證類型：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」 > 「Search End Entities」。
  • 搜尋cert-manager 終端實體，並記錄其憑證序號。
  • 依序前往「系統功能」 >「角色和存取規則」，然後按一下「新增」。
  • 將角色命名為 cert-manager，然後使用您記錄的序號新增成員。
  • 按一下「編輯存取規則」，然後設定下列權限：
    • 角色範本：RA 管理員
    • 授權 CA：GDC Subordinate CA
    • 結尾實體規則：核准、建立及編輯結尾實體
    • 終端實體設定檔：GDC TLS SERVER EE PROFILE
    • 其他規則：清除「查看稽核記錄」
  • 按一下 [儲存]。

準備 GDC 叢集

如要準備 GDC 環境，請使用標準 Kubernetes 叢集進行驗證，並將擷取的 EJBCA 管理憑證儲存在 Kubernetes Secrets 中，確保 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 驗證密鑰：

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

  • 部署 EJBCA 信任鏈結密鑰：

    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 資源，在 Kubernetes cert-manager 架構中將 EJBCA 伺服器註冊為可信任的簽署來源：

  • 設定 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

透過 DNS-01 驗證自動執行 ACME

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

為 ACME 設定 EJBCA

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

  • 在 EJBCA 管理使用者介面中，依序前往「System Configuration」 >「ACME Configuration」。
  • 按一下「新增」，然後設定下列項目：
    • Name (名稱)：default
    • 實體設定檔：GDC TLS SERVER EE PROFILE
    • 允許核發萬用字元憑證：勾選
    • 驗證回應 MPIC 驗證 DNS 識別碼驗證類型： 選取 dns-01
    • DNS 解析器：輸入全域 DNS 的 IP。
    • 驗證 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。

  • 等待 DNS 傳播約 30 秒，返回 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}/。