Ubuntu 26.04 で内部 HTTPS、LDAPS、Docker registry、Keycloak、Nextcloud などを扱う場合、内部 CA や自己署名証明書を OS 側で信頼させる必要があります。証明書をサービスに配置するだけでは、クライアント側がその証明書を信頼するとは限りません。
この記事では、Ubuntu 26.04 Server で update-ca-certificates を使い、内部 CA 証明書を OS の trust store に登録する基本を整理します。DNS、時刻同期、CA 信頼、アプリケーション個別の信頼設定を分けて見ることが重要です。
自己署名証明書と内部 CA を分けて考える
証明書エラーを整理する時は、自己署名証明書と内部 CA を分けて考えます。サーバー証明書そのものを各クライアントに信頼させるのではなく、基本的には発行元である CA 証明書を信頼させます。
| 種類 | 意味 | 信頼設定の考え方 |
|---|---|---|
| サーバー証明書 | HTTPS や LDAPS の endpoint が提示する証明書 | サービス側へ配置する |
| 秘密鍵 | サーバー証明書に対応する private key | 厳密に保護する |
| CA 証明書 | サーバー証明書を発行した認証局の証明書 | クライアント側で信頼する |
| 中間証明書 | root CA と server cert の間にある証明書 | chain として扱う |
Ubuntu の OS trust store に登録するのは、通常は CA 証明書です。サーバー証明書や秘密鍵を trust store に置くものではありません。
現在の CA trust を確認する
まず、CA 証明書を置く場所と、反映後に生成される bundle を確認します。
ls -l /usr/local/share/ca-certificates
ls -l /etc/ssl/certs
ls -l /etc/ssl/certs/ca-certificates.crt
update-ca-certificates --help/etc/ssl/certs/ca-certificates.crt は、多くのコマンドラインツールが参照する CA bundle です。ただし、すべてのアプリケーションがこの bundle だけを見るわけではありません。Java、Firefox、独自 runtime などは別の trust store を持つことがあります。
CA 証明書を配置する
内部 CA 証明書を /usr/local/share/ca-certificates/ に配置します。ファイル拡張子は .crt にします。
sudo mkdir -p /usr/local/share/ca-certificates/internal
sudo cp internal-root-ca.crt /usr/local/share/ca-certificates/internal/internal-root-ca.crt
sudo chmod 644 /usr/local/share/ca-certificates/internal/internal-root-ca.crt
openssl x509 -in /usr/local/share/ca-certificates/internal/internal-root-ca.crt -noout -subject -issuer -dates -fingerprint -sha256配置する証明書が本当に CA 証明書であるか、subject、issuer、期限、fingerprint を確認します。誤ってサーバー証明書を CA として登録すると、切り分けが分かりにくくなります。
update-ca-certificates で反映する
CA 証明書を配置したら、update-ca-certificates を実行して OS の trust store に反映します。
sudo update-ca-certificates
ls -l /etc/ssl/certs | grep internal
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt /usr/local/share/ca-certificates/internal/internal-root-ca.crtupdate-ca-certificates は、/usr/local/share/ca-certificates/ 配下の .crt を取り込み、/etc/ssl/certs/ と CA bundle を更新します。反映後に symlink や bundle の更新を確認します。
curl で HTTPS 接続を確認する
OS trust store に登録できたら、内部 HTTPS endpoint へ curl で接続確認します。
curl -v https://service.example.internal/
curl --cacert /usr/local/share/ca-certificates/internal/internal-root-ca.crt https://service.example.internal/通常の curl で成功するなら、OS 側の trust store で信頼できています。--cacert を指定した場合だけ成功するなら、証明書自体は正しいが OS trust store への登録が不足している可能性があります。
openssl s_client で証明書チェーンを確認する
curl だけでは、どの証明書が提示されているか見えにくいことがあります。openssl s_client で server certificate と chain を確認します。
openssl s_client -connect service.example.internal:443 -servername service.example.internal -showcerts 確認するのは、証明書の CN / SAN、issuer、有効期限、chain、検証結果です。DNS 名と証明書の SAN が一致していない場合、CA を信頼していても検証は失敗します。
証明書エラーを切り分ける
証明書エラーは、CA 信頼だけが原因とは限りません。DNS、時刻、SAN、chain、サービス側の証明書配置を分けて確認します。
| 症状 | 見るもの |
|---|---|
| 名前が一致しない | DNS 名と証明書 SAN |
| 期限切れに見える | 証明書期限と OS 時刻 |
| unknown CA | CA trust store と chain |
| curl は通るが Java は失敗 | アプリケーション個別の trust store |
| IP 直指定で失敗 | 証明書 SAN に IP が含まれるか |
date
getent hosts service.example.internal
resolvectl query service.example.internal
openssl x509 -in /usr/local/share/ca-certificates/internal/internal-root-ca.crt -noout -text | grep -E 'Subject:|Issuer:|Not Before|Not After|CA:'
curl -v https://service.example.internal/CA を登録しても、時刻がずれていれば証明書が期限外に見えます。DNS 名と SAN が一致していなければ、信頼済み CA で発行されていても検証に失敗します。
削除する場合
登録した CA 証明書を削除する場合は、配置した .crt を削除し、再度 update-ca-certificates を実行します。
sudo rm /usr/local/share/ca-certificates/internal/internal-root-ca.crt
sudo update-ca-certificates --fresh
ls -l /etc/ssl/certs | grep internal--fresh は symlink を再生成します。削除後は、対象 CA が残っていないか、対象 endpoint への接続が期待通り失敗するかを確認します。
アプリケーション個別の信頼設定を分ける
OS trust store に CA を登録しても、すべてのアプリケーションがそれを使うとは限りません。特に Java、Firefox、一部のコンテナ、アプリケーション組み込み runtime は独自の trust store を持つことがあります。
- OS の trust store は
update-ca-certificatesで管理する - Java は
keytoolと Java keystore を使う場合がある - コンテナは image 内の CA bundle を更新する必要がある
- アプリケーションが独自 CA 設定を持つ場合がある
- サービス証明書の配置とクライアント側の CA 信頼は別に扱う
この違いを混同すると、OS では curl が成功するのにアプリケーションだけ失敗する、という状態になります。その場合は OS ではなくアプリケーション側の trust store を確認します。
参考書籍
関連する記事
まとめ
Ubuntu 26.04 で内部 CA や自己署名証明書を扱う場合、サービス側に証明書を配置することと、クライアント側で CA を信頼することを分けて考えます。OS 側で CA を信頼させる基本は、/usr/local/share/ca-certificates/ に CA 証明書を置き、update-ca-certificates を実行することです。
証明書エラーが出た場合は、CA trust だけでなく、DNS、時刻同期、SAN、chain、アプリケーション個別の trust store を分けて確認します。この切り分けができると、内部 HTTPS、LDAPS、Docker registry、Keycloak などの TLS 設定を扱いやすくなります。
関連記事
Ubuntu 22.04 update-ca-certificates – 内部 CA と自己署名証明書を信頼する
Ubuntu 22.04 apt update / apt upgrade の基本 – 手動アップデートの確認手順
Ubuntu 26.04 自己署名証明書の配置 – 証明書と秘密鍵を安全に管理する
Ubuntu 26.04 systemd-resolved の基本 – DNS 設定と名前解決を確認する
Ubuntu 26.04 policy based routing の基本 – 複数 NIC で送信元ごとに経路を分ける
Ubuntu 26.04 kubeconfig の基本 – kubectl の context と複数クラスタ管理
Ubuntu 26.04 MicroK8s の基本 – snap で単体 Kubernetes を構築する
Ubuntu 26.04 Apache TLS の設定 – HTTPS VirtualHost を有効化する