top of page
検索

自宅で簡単、Ubuntu VMで作るCA構築：EJBCA Communityで学ぶCAの基本

  • 5月26日
  • 読了時間: 6分

CA を学ぶとき、OpenSSL だけでは少し見えにくいものがあります。たとえば、管理者は誰なのか、どの利用者にどのプロファイルで証明書を出すのか、発行後の監査や権限分離をどう考えるのか、といった運用の側面です。そうした“ちゃんとした PKI”の空気を自宅 lab に持ち込みやすいのが EJBCA Community です。公式には Community コンテナを使った quick start が用意されており、Docker で短時間に試せます。

EJBCA の良さは、単に証明書を一枚作るだけで終わらないことです。CA、エンドエンティティ、管理者証明書、プロファイルといった要素が UI 上で見え、PKI を“運用する仕組み”として理解しやすい構造になっています。自宅環境でも、企業や組織で使う CA 製品の手触りをかなり具体的に確認できます。 (docs.keyfactor.com)


この記事で扱う内容


今回は Ubuntu VM 上で Docker を使って EJBCA Community を起動し、以下を確認します。

  • Docker 環境の準備

  • EJBCA Community コンテナの起動

  • 管理 UI へのアクセス

  • lab 向けの簡易構成での動作確認

  • エンドエンティティと証明書発行の基本的な流れ


Keyfactor の公式ドキュメントには、未認証ネットワークアクセスの簡易起動手順と、クライアント証明書認証を使うより厳密な起動手順の両方があります。今回は学習の入り口として分かりやすい簡易構成を使います。


検証環境

  • Ubuntu 22.04 の VM

  • Docker と Docker Compose


手順


1. Docker を導入する

sudo apt update
sudo apt install -y ca-certificates curl gnupg

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Docker が使える状態になれば準備完了です。EJBCA Community は Docker Hub から取得でき、公式ガイドもコンテナ前提で進みます。


2. 作業ディレクトリを作る

mkdir -p ~/ejbca-lab
cd ~/ejbca-lab

3. Compose ファイルを作る

docker-compose.yml を以下の内容で作成します。

services:
  ejbca:
    image: keyfactor/ejbca-ce
    container_name: ejbca
    ports:
      - "8080:8080"
      - "8443:8443"
    environment:
      - TLS_SETUP_ENABLED=simple
    restart: unless-stopped

この設定は lab 用です。HTTPS アクセスできる利用者に管理画面が開いてしまうため、試験・評価用途に限定して使います。これは公式の unauthenticated quick start の前提そのものです。


4. 起動する

sudo docker compose up -d
sudo docker ps

必要に応じてログも見ます。

sudo docker logs -f ejbca

コンテナが起動し、ポート 8443 が待ち受ければ次に進めます。


5. 管理 UI にアクセスする

ブラウザで以下にアクセスします。

https://<Ubuntu-VMのIP>:8443/ejbca/adminweb

初回は証明書警告が出るはずです。lab 用の自己署名系構成なので正常です。ブラウザで警告を承知のうえ進むと、EJBCA の管理 UI に入れます。



証明書発行までの具体的な流れ


ここからが本題です。EJBCA を“見るだけ”で終わらせず、実際に証明書を発行して取り出すところまで進めます。


6. Certificate Profile を作る

まず、どんな用途の証明書を発行するかを定義します。管理画面でCA FunctionsからCertificate Profilesを開きます。既存の ENDUSER などを複製して、ENDUSER2を作ります。



Viewでprofileの内容を確認できます。

  • アルゴリズム

  • 鍵長

  • 有効期限

  • Key Usage

  • Extended Key Usage

  • Subject DN の扱い

  • Subject Alternative Name の扱い

などを確認できます。


7. End Entity Profile を作る

次に、利用者や端末など、証明書を受け取る主体の属性を定義します。管理画面でRA FunctionsからEnd Entity Profiles次へ進みます。


ここでは、DEVICEという名前で新規作成します。

  • Common Name を入力必須にするか

  • Email を使うか

  • Subject DN に何を含めるか

  • 証明書プロファイル候補を何にするか

など、かなり細かく設定できます。



8. エンドエンティティを登録する

次に、実際の発行対象を登録します。管理画面でRA FunctionsからAdd End Entityへ進みます。


次のように設定します。

  • Username: enduser2

  • Password / Enrollment Code: 任意の仮パスワード

  • CN: enduser2

  • CA: デフォルトのままとします

  • Certificate Profile: ENDUSER

  • End Entity Profile: DEVICE

  • Token: P12 file または Browser Generated


ここでは P12 file にしておきます。これなら発行後に .p12 / .pfx ファイルとしてダウンロードし、そのままブラウザや OS に取り込めます。


9. 証明書を発行する

エンドエンティティ登録後、そのユーザーに対して証明書を発行します。メニューにあるRA WebからRA GUIを開き、Enroll → Use Usernameに進みます。先程のEnd Entities登録したUser NameとEnrollment codeを入力します。



PKCS#12 (.p12) をダウンロードします。


10. 発行した PKCS#12 を確認する

ダウンロードした .p12 の中身は、Ubuntu 側で OpenSSL を使えば確認できます。

openssl pkcs12 -in enduser2.p12 -info -nodes

ここで、秘密鍵、クライアント証明書、CA 証明書チェーンが含まれているかを見ます。発行された証明書だけを個別に取り出すなら、たとえば次のようにできます。

openssl pkcs12 -in enduser2.p12 -clcerts -nokeys -out issued.crt
openssl pkcs12 -in enduser2.p12 -nocerts -nodes -out issued.key

その後、証明書内容を確認します。

openssl x509 -in issued.crt -text -noout

Issuer、Subject、Key Usage、Extended Key Usage を見ると、証明書プロファイルで設定した内容が反映されていることが分かります。


11. CA 証明書も確認する

証明書チェーンを確認するため、CA 証明書も取得しておくと良いでしょう。EJBCA のホームに戻り、CA FunctionsからCA Structure & CRLsに進みます。ここからCA証明書を取得できます。


取得した Root CA / Intermediate CA をもとに、証明書チェーン検証もできます。

openssl verify -CAfile ManagementCA.cacert.pem issued.crt

向いている用途


EJBCA Community は、次のような用途に向いています。

  • 企業 PKI の基本構造を自宅で学びたい

  • UI を見ながら CA を理解したい

  • エンドエンティティや証明書プロファイルの概念を掴みたい

  • 将来的に RA、管理権限、監査まで見据えたい

単に短命証明書を API で配るだけなら Vault のほうが軽快ですが、CA の“運用らしさ”を学ぶには EJBCA のほうが分かりやすいです。


まとめ


EJBCA を触ると、PKI は単に鍵と証明書を作るだけの仕組みではなく、証明書発行そのものを運用する仕組みであることがよく見えてきます。管理者がいて、登録された主体がいて、発行ルールがあり、それらを画面上で管理する。つまり、CA は“署名するソフト”ではなく、“誰に、どの条件で、どう証明書を発行するか”を扱うための運用基盤ですCommunity 版でも、その感覚はかなりしっかり掴めます。


Vault が自動化寄りの PKI だとすれば、EJBCA は運用寄りの PKI です。証明書発行を人や業務の流れの中でどう扱うのかを理解したいとき、UI があることの意味は大きいです。とくに、証明書プロファイルとエンドエンティティプロファイルを分けて管理する設計は、OpenSSL だけでは実感しにくい、CA 製品らしさの一つだと感じます。


自宅 lab で CA を立てる方法はいくつもありますが、EJBCA Community はその中でもかなり正統派です。管理画面があり、主体があり、プロファイルがあり、発行の意味が見える。OpenSSL の延長としてではなく、CA 製品そのものの感触を確かめたいなら、とても良い選択肢です。実際にエンドエンティティを登録し、証明書プロファイルを作り、PKCS#12 を発行して中身を確認するところまで進めると、EJBCA の価値はさらに明確になります。Ubuntu VM 一台と Docker だけでここまで試せるのは、学習環境としてかなり優秀です。

bottom of page