Ubuntu 26.04 easy-rsa の基本 – 内部 CA と SAN 付き証明書を作成する

Ubuntu 26.04 で内部向けの TLS 証明書を扱う場合、単に openssl で自己署名証明書を作るだけでは運用が弱くなります。複数のサーバー証明書、クライアント証明書、失効、更新を考えるなら、内部 CA と PKI の作業場所を分けて管理した方が扱いやすくなります。

この記事では、Easy-RSA を使って内部 CA を作成し、SAN 付きサーバー証明書を発行する基本手順を整理します。Ubuntu 26.04 のサーバー管理ガイドの中では、証明書を作る側の作業として位置づけます。信頼ストアへ登録する作業は update-ca-certificates 側で扱います。

Easy-RSA で管理する範囲

Easy-RSA は、OpenSSL を直接たたくよりも CA、証明書発行、失効、CRL 生成をまとめて扱いやすくするための道具です。内部 CA を小さく運用する場合でも、証明書を単発で作るのではなく、PKI の状態をディレクトリとして残せる点が重要です。

実運用では、RSA と EdDSA を同じ PKI に混ぜず、用途ごとに作業ディレクトリを分ける方が見通しが良くなります。たとえば、汎用的な TLS や EAP-TLS は RSA、ルーターや VPN など Ed25519 を使いたい領域は EdDSA として分ける、という整理です。

Easy-RSA を用意する

Ubuntu 26.04 では easy-rsa パッケージを入れ、作業用ディレクトリへ Easy-RSA の雛形をコピーして使います。PKI の作業場所には秘密鍵が作成されるため、通常の公開ディレクトリや共有ディレクトリには置かない方が安全です。

sudo apt update
sudo apt install -y easy-rsa
mkdir -p ~/work/easy-rsa/rsa
cp -a /usr/share/easy-rsa/. ~/work/easy-rsa/rsa
cd ~/work/easy-rsa/rsa

複数の PKI を分ける場合は、同じ要領で別ディレクトリを作成します。RSA 用と EdDSA 用を分けると、鍵種別や証明書用途の混在を避けやすくなります。

mkdir -p ~/work/easy-rsa/eddsa
cp -a /usr/share/easy-rsa/. ~/work/easy-rsa/eddsa

RSA 用の vars を作成する

vars には、Easy-RSA の PKI 方針を書きます。内部向けの TLS 証明書では、DN を CN 中心にし、鍵種別、有効期間、CRL の期間、更新猶予などを明示しておくと運用時に迷いにくくなります。

cat > vars <<'EOF'
if [ -z "$EASYRSA_CALLER" ]; then
return 1
fi
set_var EASYRSA_DN cn_only
set_var EASYRSA_ALGO rsa
set_var EASYRSA_KEY_SIZE 2048
set_var EASYRSA_DIGEST sha512
set_var EASYRSA_CA_EXPIRE 3650
set_var EASYRSA_CERT_EXPIRE 365
set_var EASYRSA_CRL_DAYS 3650
set_var EASYRSA_CERT_RENEW 60
set_var EASYRSA_RAND_SN yes
set_var EASYRSA_NS_SUPPORT no
set_var EASYRSA_BATCH 1
EOF

RSA 2048 は現在でも多くの製品やミドルウェアで扱いやすい選択肢です。内部 CA の運用では、暗号方式の新しさだけでなく、利用側の互換性も含めて判断します。

PKI を初期化して CA を作成する

PKI を初期化し、内部 CA を作成します。CA 秘密鍵のパスフレーズは記事や手順書に残さず、別の安全な方法で管理します。

./easyrsa init-pki
./easyrsa --req-cn="example internal RSA CA" build-ca

作成後は、CA 証明書の subject、issuer、有効期限を確認します。CA 証明書は配布対象ですが、CA 秘密鍵は配布してはいけません。

openssl x509 -in pki/ca.crt -noout -subject -issuer -dates
openssl x509 -in pki/ca.crt -noout -fingerprint -sha256

初期 CRL を作成する

証明書を発行するだけでなく、失効させる手順も最初から作っておきます。CRL を使う予定がある場合、初期状態の CRL を生成しておくと、利用側の設定を先に固められます。

./easyrsa build-server-full dummy nopass
./easyrsa revoke dummy
./easyrsa gen-crl
openssl crl -in pki/crl.pem -noout -issuer -lastupdate -nextupdate

ダミー証明書は、CRL の生成と配布手順を確認するためのものです。本番の証明書と混同しない名前にしておくことが重要です。

SAN 付きサーバー証明書を発行する

現在の TLS 証明書では、Common Name だけではなく SAN を正しく入れることが重要です。ブラウザ、curl、Java、Go、各種ミドルウェアでは、SAN の有無や内容が検証結果に影響します。

BASE_DOMAIN=example.internal
name="server01.$BASE_DOMAIN"
./easyrsa --req-cn="$name" --subject-alt-name="DNS:$name,DNS:server01" build-server-full "$name" nopass

ワイルドカード証明書を発行する場合も、SAN にワイルドカード名を入れます。ワイルドカード証明書は便利ですが、秘密鍵の影響範囲が広くなるため、用途と配置先を絞って扱います。

BASE_DOMAIN=example.internal
name="mgmt.$BASE_DOMAIN"
./easyrsa --req-cn="*.$name" --subject-alt-name="DNS:*.$name" build-server-full "$name" nopass

証明書の内容を確認する

証明書を発行したら、Subject、Issuer、有効期限、SAN、鍵種別を確認します。発行に成功したかだけでなく、利用側が検証する名前が入っているかを見ます。

name="server01.example.internal"
openssl x509 -in "pki/issued/$name.crt" -noout -subject -issuer -dates
openssl x509 -in "pki/issued/$name.crt" -noout -ext subjectAltName
openssl verify -CAfile pki/ca.crt "pki/issued/$name.crt"

証明書エラーの多くは、CA が信頼されていない、SAN が足りない、接続先名と証明書名が一致していない、時刻がずれている、のいずれかです。証明書だけを見ず、DNS と時刻同期も合わせて確認します。

EdDSA 用 PKI を分ける

Ed25519 を使いたい用途がある場合は、RSA とは別の PKI ディレクトリを作ります。すべてを EdDSA に寄せるのではなく、利用側が対応しているか、どの用途で使うかを確認してから採用します。

cd ~/work/easy-rsa/eddsa
cat > vars <<'EOF'
if [ -z "$EASYRSA_CALLER" ]; then
return 1
fi
set_var EASYRSA_DN cn_only
set_var EASYRSA_ALGO ed
set_var EASYRSA_CURVE ed25519
set_var EASYRSA_CA_EXPIRE 3650
set_var EASYRSA_CERT_EXPIRE 365
set_var EASYRSA_CRL_DAYS 3650
set_var EASYRSA_CERT_RENEW 60
set_var EASYRSA_RAND_SN yes
set_var EASYRSA_NS_SUPPORT no
set_var EASYRSA_BATCH 1
EOF
./easyrsa init-pki
./easyrsa --req-cn="example internal EdDSA CA" build-ca

EdDSA は鍵が短く扱いやすい一方で、古い製品や一部の連携先では対応が弱いことがあります。内部 CA では、暗号方式を新しくすることよりも、証明書を使う側の実装で検証できることを優先します。

クライアント証明書と PKCS#12

EAP-TLS や VPN などでクライアント証明書を配布する場合は、証明書と秘密鍵を PKCS#12 にまとめることがあります。PKCS#12 は秘密鍵を含むため、配布経路と保管場所を証明書単体より強く管理します。

name="client01.example.internal"
./easyrsa --subject-alt-name="DNS:$name" build-client-full "$name" nopass
mkdir -p pki/pkcs12
openssl pkcs12 -export -inkey "pki/private/$name.key" -in "pki/issued/$name.crt" -certfile pki/ca.crt -out "pki/pkcs12/$name.p12"

クライアント証明書では、発行、配布、失効、再発行の流れを事前に決めておきます。証明書認証は強力ですが、端末を紛失した時に失効できない設計では運用が成立しません。

証明書を失効して CRL を更新する

証明書を廃止する場合は、単にファイルを削除するのではなく、CA 側で失効し、CRL を再生成します。CRL を参照するサービスがある場合は、更新後の CRL を配布する必要があります。

./easyrsa revoke client01.example.internal
./easyrsa gen-crl
openssl crl -in pki/crl.pem -noout -issuer -lastupdate -nextupdate

CRL を生成しても、利用側が CRL を見ていなければ失効は効きません。証明書を発行する側と、証明書を検証する側の両方で設計する必要があります。

証明書を更新する

証明書の有効期限が近づいたら、Easy-RSA の更新猶予期間内で更新します。更新対象は CA ではなく、通常はサーバー証明書やクライアント証明書です。

./easyrsa renew server01.example.internal
openssl x509 -in pki/issued/server01.example.internal.crt -noout -subject -issuer -dates

更新後は、サービスへ配置した証明書を差し替え、必要に応じてサービスを再読み込みします。証明書ファイルを更新しただけでは、実行中のプロセスが古い証明書を保持している場合があります。

CA 証明書を Ubuntu 側で信頼する

内部 CA で発行した証明書を Ubuntu 26.04 側で信頼するには、CA 証明書を OS の信頼ストアに登録します。証明書を作る作業と、信頼させる作業は分けて考えます。

sudo cp pki/ca.crt /usr/local/share/ca-certificates/internal-root-ca.crt
sudo update-ca-certificates

まとめ

Easy-RSA は、内部 CA、サーバー証明書、クライアント証明書、CRL、更新を小さく管理するための実用的な道具です。Ubuntu 26.04 のサーバーで内部向け TLS を扱うなら、単発の自己署名証明書ではなく、PKI として状態を残した方が運用しやすくなります。

重要なのは、証明書を発行できることだけではありません。CA 秘密鍵を守ること、用途ごとに PKI を分けること、SAN を正しく入れること、失効と更新の手順を用意すること、信頼ストアへの登録を別の作業として管理することです。

関連記事

Ubuntu 22.04 easy-rsa – 内部 CA と SAN 付き自己署名証明書を作成する Ubuntu 26.04 update-ca-certificates の基本 – 内部 CA と自己署名証明書を信頼する Ubuntu 26.04 自己署名証明書の配置 – 証明書と秘密鍵を安全に管理する Ubuntu 26.04 systemd-resolved の基本 – DNS 設定と名前解決を確認する Ubuntu 26.04 policy based routing の基本 – 複数 NIC で送信元ごとに経路を分ける Ubuntu 26.04 Apache TLS の設定 – HTTPS VirtualHost を有効化する Ubuntu 26.04 kubeconfig の基本 – kubectl の context と複数クラスタ管理 Ubuntu 26.04 MicroK8s の基本 – snap で単体 Kubernetes を構築する