手当たり次第に書くんだ

飽きっぽいのは本能

Ubuntu 22.04 update-ca-certificates – 内部 CA と自己署名証明書を信頼する

Ubuntu 22.04 で自己署名証明書や内部 CA の証明書を使う場合、単に証明書ファイルを置くだけではなく、OS の信頼ストアへ登録する必要があります。update-ca-certificates は、そのための基本的なコマンドです。

この記事では、Ubuntu 22.04 に内部 CA 証明書を配置し、curlopenssl s_client、LDAPS などで証明書検証できる状態にする手順を整理します。ポイントは、個別のサーバー証明書を場当たり的に信頼するのではなく、原則として内部 CA を信頼することです。

参考書籍
参考書籍

暗号技術入門 第3版 秘密の国のアリス

公開鍵暗号、電子署名、証明書など、TLS や内部 PKI の前提になる暗号技術を確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。

Amazon で見る

このリンクは Amazon アソシエイトリンクです。

関連する記事

証明書の作成、内部 PKI の設計、LDAPS の確認と合わせて読むと、何をどこに配置するべきかが分かりやすくなります。

自己署名証明書と内部 CA 証明書を分けて考える

自己署名証明書という言葉は広く使われますが、実運用では少し分けて考えた方が安全です。サーバー証明書そのものを自己署名して配る構成と、内部 CA を作り、その CA でサーバー証明書を発行する構成では、管理のしやすさが違います。

方式考え方注意点
サーバー証明書を直接信頼各サーバー証明書をクライアントへ登録するサーバーが増えるほど管理が崩れやすい
内部 CA を信頼内部 CA 証明書をクライアントへ登録し、サーバー証明書は CA で発行するCA 秘密鍵の管理が重要になる
公開 CA を利用Let’s Encrypt などの公開 CA で証明書を発行する内部名や閉域名では使いにくい場合がある

社内、検証環境、ホームラボのような内部システムでは、内部 CA を信頼させる構成が扱いやすいです。信頼する対象をサーバー証明書ではなく CA に寄せることで、証明書更新やサーバー追加時の作業を減らせます。

CA 証明書を配置する

Ubuntu では、追加で信頼したい CA 証明書を /usr/local/share/ca-certificates/ に配置します。ファイル拡張子は .crt にします。

sudo install -m 0644 internal-ca.crt /usr/local/share/ca-certificates/internal-ca.crt
sudo update-ca-certificates

update-ca-certificates を実行すると、/etc/ssl/certs/ 以下の CA 証明書リンクと、/etc/ssl/certs/ca-certificates.crt が更新されます。多くの CLI ツールは、この OS 側の CA バンドルを参照します。

配置結果を確認する

CA 証明書が取り込まれたかは、コマンドの出力とファイルの有無で確認します。

sudo update-ca-certificates --fresh
ls -l /etc/ssl/certs | grep internal
grep -n 'BEGIN CERTIFICATE' /etc/ssl/certs/ca-certificates.crt | tail

証明書名によっては、/etc/ssl/certs/ のリンク名がハッシュ値ベースになるため、ファイル名そのままで見つからない場合があります。その場合でも、update-ca-certificates の出力や実際の TLS 接続確認で判断します。

curl で HTTPS 接続を確認する

内部 CA で発行した HTTPS サーバーへ接続し、証明書検証が通るか確認します。

curl -v https://internal.example.local/

CA が信頼されていない場合、curl は証明書検証エラーを出します。-k--insecure で回避することもできますが、運用手順としては避けた方がよいです。--insecure は確認用の逃げ道であり、信頼設定の代替ではありません。

openssl s_client で証明書チェーンを確認する

証明書チェーンや検証結果を詳しく確認する場合は、openssl s_client を使います。SNI が必要なサーバーでは -servername も指定します。

openssl s_client \
  -connect internal.example.local:443 \
  -servername internal.example.local \
  -verify_return_error \
  -CAfile /etc/ssl/certs/ca-certificates.crt

検証が通る場合は、出力の最後付近に Verify return code: 0 (ok) が表示されます。ここでエラーになる場合は、CA の配置、証明書チェーン、サーバー名、SAN、期限を確認します。

LDAPS で確認する

SSSD や LDAP クライアントで LDAPS を使う場合も、OS 側の CA 信頼が重要です。LDAP サーバー証明書を内部 CA で発行している場合、クライアント側で内部 CA を信頼しておきます。

ldapwhoami -H ldaps://ldap.example.local \
  -D 'cn=ro,ou=service,dc=example,dc=local' \
  -W

SSSD の設定で ldap_tls_reqcert = demand を使う場合、証明書検証に失敗すると LDAP 認証も失敗します。これは面倒に見えますが、認証基盤としては正しい失敗です。証明書検証を無効化するのではなく、CA 配置とサーバー証明書の SAN を直す方が安全です。

削除する場合

信頼を取り消す場合は、配置した CA 証明書を削除してから update-ca-certificates を再実行します。

sudo rm /usr/local/share/ca-certificates/internal-ca.crt
sudo update-ca-certificates --fresh

CA を削除すると、その CA で発行された内部サーバー証明書は信頼されなくなります。影響範囲が広いため、内部 CA の削除やローテーションは、利用しているサービスを確認してから実施します。

アプリケーションごとの注意

すべてのアプリケーションが Ubuntu の OS 信頼ストアをそのまま使うとは限りません。特に Java、Firefox、コンテナ内アプリケーション、一部の言語ランタイムでは、別の CA ストアを持つことがあります。

対象注意点
curl / OpenSSL 系ツール多くの場合、OS の CA バンドルを参照する
LDAP / SSSDLDAPS の証明書検証で OS 側の CA が関係する
Java アプリケーションJVM の truststore に別途登録が必要な場合がある
Firefox独自証明書ストアを使う構成がある
Docker / コンテナホストではなくコンテナイメージ内の CA 配置が必要になる場合がある

設計上の注意

内部 CA を使う場合、CA 証明書の配布よりも CA 秘密鍵の保護が重要です。クライアントへ配るのは公開情報である CA 証明書ですが、サーバー証明書を発行できる CA 秘密鍵が漏れると、内部名の偽装が可能になります。

  • クライアントには CA 証明書だけを配布する
  • CA 秘密鍵は通常のサーバーに置きっぱなしにしない
  • サーバー証明書には CN だけでなく SAN を設定する
  • 証明書検証を無効化する設定を恒久運用にしない
  • 公開 CA、内部 CA、自己署名サーバー証明書の役割を混同しない

まとめ

Ubuntu 22.04 で内部 CA や自己署名証明書を扱う場合、/usr/local/share/ca-certificates/ に CA 証明書を配置し、update-ca-certificates で OS の信頼ストアへ反映します。

重要なのは、証明書エラーを --insecure や検証無効化で回避することではなく、どの CA を信頼し、その CA でどのサーバー証明書を発行するのかを設計することです。LDAPS、HTTPS、SSSD のような認証・通信基盤では、証明書検証が通る状態を正として構成する方が安定します。

Ubuntu 22.04 update-ca-certificates – 内部 CA と自己署名証明書を信頼する

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)

トップへ戻る