Keyfactor EJBCA リファレンス実装

概要

このガイドでは、Google Distributed Cloud（GDC）エアギャップのサードパーティ認証局（CA）として Keyfactor EJBCA Enterprise（外部アプライアンスとしてデプロイ）を統合する方法について説明します。

Keyfactor EJBCA Enterprise は、スケーラビリティと堅牢性に優れた FIPS 準拠の認証局プラットフォームです。組織は、異種環境全体で公開鍵基盤（PKI）を管理できます。

GDC エアギャップには、ホストされたクラウド境界内で鍵と証明書の管理を自動化するための組み込みの Certificate Authority Service が含まれています。ただし、GDC 外の既存のワークロードに対して Keyfactor EJBCA で PKI インフラストラクチャを標準化している組織は、エアギャップのある GDC 環境内で実行されるワークロードに同じ一貫した CA アーキテクチャと管理ポリシーを活用することをおすすめします。

このガイドでは、GDC ネットワーキング、内部 DNS、Kubernetes cert-manager を構成して、証明書のライフサイクル管理（ACME）を自動化し、登録機関（RA）パターンを使用して大量のプログラムによる発行をサポートする方法について説明します。

前提条件

このガイドに進む前に、次の前提条件を満たしていることを確認してください。

  • Keyfactor EJBCA は、ソフトウェア アプライアンスまたはハードウェア アプライアンスとしてデプロイされ、サービスに安定した IP アドレスが構成されます。
  • ルート、下位、管理の認証局（CA）が EJBCA インスタンスに作成されている。
  • エンド エンティティ（EE）プロファイルが構成されている（TLS サーバー証明書など）。
  • 管理 CA ユーザーの証明書がダウンロードされました。
  • 必要なプロトコル（ACME など）が EJBCA インスタンスで有効になっている。
  • このガイドでは、RSA 署名アルゴリズムを使用します。署名アルゴリズムは、特定の要件または EJBCA インスタンスで構成されている内容に基づいて変更できます。

アーキテクチャ

このアーキテクチャは外部認証局モデルに従っています。このモデルでは、EJBCA サーバーとそのバックアップ ハードウェア セキュリティ モジュール（HSM）は、物理的な GDC 境界の外でホストされますが、ネットワーク経由でアクセスできます。EJBCA サーバーは、ハードウェアまたはソフトウェア アプライアンスとして外部にデプロイできます。このガイドで説明するコア統合では、外部 EJBCA サーバーに安定した IP アドレスを使用してアクセスできることのみが必要です。

Keyfactor EJBCA のアーキテクチャ図。

このアーキテクチャの主なコンポーネントは次のとおりです。

  • EJBCA Enterprise Server: Keyfactor ハードウェア アプライアンスまたはソフトウェア アプライアンスとして外部にデプロイされ、CA（ルートと下位）を格納し、CC EAL4+ 認定 HSM 内ですべての CA 鍵マテリアルを生成します。
  • GDC 標準 Kubernetes クラスタ: 顧客ワークロード、cert-manager、統合プロキシを実行するコンピューティング環境。
  • GDC 内部 DNS: ACME DNS-01 チャレンジの解決に使用されるローカルの限定公開 DNS ゾーン（環境変数で構成された限定公開ドメイン名を使用）を管理します。
  • GDC Egress Gateway: クラスタ Pod から外部 EJBCA サーバーの IP アドレスにアウトバウンド トラフィックを転送します。
  • Harbor Private Registry: エアギャップ デプロイ用のミラーリングされたコンテナ イメージ（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 に便利なコマンドライン エイリアスを作成します。

  • ゾーン管理 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 クラスタのワーカーノードに適したマシンタイプを選択します。

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

3 ゾーン管理 API を使用して、2 つのワーカーノードを含む標準クラスタを作成します。

```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 ゲートウェイの設定

次に、カスタム サブネットと NAT ゲートウェイを設定して GDC 下り（外向き）ネットワーキングを構成し、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
    • Issuer Alternative Name: [Use] をオフにします。
    • CRL Distribution Points: [Use] をオンにします。
    • CA で定義された CRL 配布ポイントを使用する: [使用] をオンにします。
    • 認証局情報アクセス: [使用] をオンにします。
    • Use CA defined OCSP locator: [Use] をオンにします。
    • Use CA defined CA issuer: [Use] をオンにします。
    • 利用可能な 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）インターフェースを使用して管理 ID を登録し、秘密鍵、公開証明書、信頼チェーンを抽出して、cert-manager の認証に必要な物理的な証明書ファイルを生成します。

  • [RA Web] タブに移動します。
  • [Make New Request] をクリックして、次のように構成します。
    • 証明書の種類: GDC ADMIN EE PROFILE
    • 鍵ペアの生成: CA による
    • 鍵アルゴリズム: RSA 4,096 ビット
    • 共通名（CN）: cert-manager
    • ユーザー名: cert-manager
    • 登録コード: abcd
  • [PEM をダウンロード] をクリックし、cert-manager.pem として保存します。

  • PEM ファイルを次の 3 つのファイルに分割します。

    • 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 証明書とルート CA 証明書を含む信頼チェーン）:

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

ロールとアクセスルールを構成する

最後に、EJBCA で管理ロールを作成し、cert-manager 証明書のシリアル番号にバインドして、発行者に証明書の承認とリクエストに必要な最小限の権限セットのみが付与されるようにします。

  • EJBCA 管理 UI で、[RA Functions] > [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}"

  • カスタム発行者のターゲット Namespace を作成します。

    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 呼び出しに変換するために必要なカスタム コントローラがインスタンス化されます。

  • 発行元の Namespace に Harbor イメージ pull シークレットを作成します。

    # 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 フレームワーク内の信頼できる署名ソースとして登録されます。

  • GDC の cert-manager コントローラがカスタム EJBCA 発行元を使用できるように RBAC 権限を構成します。

    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 Certificate リソースをデプロイして、エンドツーエンドの 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 管理 UI で、[System Configuration] > [ACME Configuration] に移動します。
  • [追加] をクリックして、以下を構成します。
    • 名前: 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}/ に正常に書き込まれていることを確認します。