top of page
検索

自宅で簡単、Ubuntu VMで作るCA構築：HashiCorp Vaultで始める証明書発行環境

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

証明書を自宅で試そうとすると、多くの人はまず OpenSSL を思い浮かべるはずです。秘密鍵を作り、CSR を作り、署名し、必要なら失効や配布を考える。PKI を学ぶ入り口としては王道ですが、運用の現場では証明書のライフサイクル全体を管理できるような仕組みが利用されています。


HashiCorpのVaultは、OpenSSLよりも何段階もステップアップした証明書管理が行えるツールの一つです。また、証明書管理の自動化を前提にした仕組みを味わえるのがVaultの特徴でもあります。誰が、どんな条件で、どんな寿命の証明書を受け取れるかをAPIとポリシーにより制御するという思想で作られています。HashiCorp 公式でも、通常の手動フローを経ずに動的な X.509 証明書を発行できる仕組みとして説明されています。 (HashiCorp Developer)


今回は、このVaultによる証明書管理サーバーを実際に構築し証明書管理の基本やVaultについて学んでいきたいと思います。


この記事で扱う内容


今回は Ubuntu VM 上に検証用の Vault サーバーを立てて、以下を確認します。

  • Vault の導入

  • PKI secrets engine の有効化

  • root CA の作成

  • 発行 URL と CRL URL の設定

  • 発行ロールの作成

  • サーバー証明書の発行


本番向けの構成には及びませんが、Vault を CA として扱うための基本的な特徴を把握するには、これ十分かと思います。


検証環境


  • Ubuntu 22.04 の VM

  • メモリ 2GB 以上


VMはHyper-V でも VirtualBox でも構いません。この記事では最短で動きを見ることを重視し、検証専用の構成で進めます。


手順


1. Vault を導入する

まずは Ubuntu VM に Vault を入れます。

sudo apt update
sudo apt install -y unzip curl wget jq
wget https://releases.hashicorp.com/vault/1.15.0/vault_1.15.0_linux_amd64.zip
unzip vault_1.15.0_linux_amd64.zip
sudo mv vault /usr/local/bin/
vault version

vault version でバージョンが表示されれば導入完了です。検証用 VM では単体バイナリで入れる方法が分かりやすく、余計な前提も少なくて済みます。


2. 開発モードで起動する

今回は lab 用なので dev モードを使います。

vault server -dev -dev-root-token-id="root"

別ターミナルを開いて、以下を設定します。

export VAULT_ADDR='http://127.0.0.1:8200'
export VAULT_TOKEN='root'
vault status

Initialized true、Sealed false が見えれば、少なくとも検証用としては起動できています。なお dev モードは本番用ではなく、あくまで機能理解のための起動方法です。


3. PKI secrets engine を有効化する

vault secrets enable pki
vault secrets tune -max-lease-ttl=87600h pki

Vault の PKI は、機能を mount して使う形です。ここでは pki/ に engine を有効化し、長めの TTL 上限を設定しています。公式資料でも、まず vault secrets enable pki を実行するのが出発点です。


4. root CA を作る

vault write pki/root/generate/internal \
  common_name="home.lab Root CA" \
  ttl=87600h

これで Vault 内部に root CA を作れます。出力には証明書やシリアル番号などが含まれます。学習段階ではこの方法が分かりやすいですが、Vault のチュートリアルでは intermediate-only CA の考え方も示されており、実運用ではそちらのほうが自然な構成になることが多いです。


5. 発行証明書 URL と CRL URL を設定する

vault write pki/config/urls \
  issuing_certificates="http://127.0.0.1:8200/v1/pki/ca" \
  crl_distribution_points="http://127.0.0.1:8200/v1/pki/crl"

この設定を入れておくと、発行された証明書の中に CA 証明書の取得先や CRL 配布先を反映しやすくなります。URL 設定は公式の setup 手順にも含まれています。


6. 発行ロールを作る

vault write pki/roles/home-lab-dot-local \
  allowed_domains="home.lab" \
  allow_subdomains=true \
  max_ttl="72h"

証明書を出すだけでなく、どのドメインに対して、どの程度の寿命で出すかをロールで制御できます。


7. サーバー証明書を発行する

vault write -format=json pki/issue/home-lab-dot-local \
  common_name="web.home.lab" > issue.json

出力から証明書、秘密鍵、発行 CA を取り出します。

jq -r '.data.certificate' issue.json > web.home.lab.crt
jq -r '.data.private_key' issue.json > web.home.lab.key
jq -r '.data.issuing_ca' issue.json > ca.crt

これで、実際に Vault から証明書一式を受け取れます。これはAPI ドキュメントで示されている通りです。


8. 証明書の内容を確認する

openssl x509 -in web.home.lab.crt -text -noout

Subject、Issuer、Validity、Key Usage、SAN を確認してみてください。ここで見えるのは単なる PEM ファイルではなく、ポリシーに従って発行された短命の証明書です。Vault を CA として見るときの肝は、この“証明書発行が API とポリシーの結果になっている”点にあります。


向いている用途


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

  • サービス間 TLS を自動化したい

  • 短命証明書の考え方を試したい

  • API ベースで証明書を払い出したい

  • DevOps や IaC と組み合わせた PKI を学びたい


逆に、承認フローや管理 UI を重視した学び方をしたいなら、EJBCA や OpenXPKI のほうが理解しやすい場面もあります。Vault は証明書運用の“自動化”に強く寄った CA です。


まとめ


Vault の PKI を実際に触ってみると、従来の CA 製品とは重心の置き方が少し違うことが見えてきます。主役になるのは証明書ファイルそのものではなく、どの主体に、どの条件で、どの範囲まで証明書を発行させるかという制御です。誰が認証され、どのロールに基づき、どのドメインに対して、どれくらいの有効期間を持つ証明書を取得できるのか。そうした発行ポリシーが最初から設計の中心に据えられています。


これは、Vault が secrets engine を通じて、秘密情報の保存・生成・保護を一貫して扱う仕組みとして設計されていることを考えれば、むしろ自然な姿です。PKI もその延長線上にあり、証明書を静的な成果物として配るのではなく、必要なときに必要な条件で払い出す対象として扱います。


短命証明書や自動更新を前提とした運用に関心があるなら、Vault はその発想を学ぶうえで非常に分かりやすい存在です。サービス間 TLS、検証用 lab の自動化、CI/CD に組み込む証明書発行といった場面では、OpenSSL ベースの手作業よりも、こちらの考え方のほうが今のシステムにはよくなじみます。さらに、ACME 連携や intermediate CA を用いた構成にも発展させやすく、まず小さく始めて、理解に合わせて段階的に広げていける点も大きな魅力です。

bottom of page