Docker がプライベート CA（例：step-ca）で発行した HTTPS 証明書を使用する場合、Docker Engine によるイメージの pull と コンテナ内のアプリケーションによる HTTPS アクセス の 2 つの状況を区別する必要があります。両者の証明書信頼ストアが同じとは限りません。
一、Docker Engine でプライベート CA を信頼する
docker login、docker pull、docker push でプライベートレジストリにアクセスする場合に適用されます。
指定した Registry のみを信頼する（推奨）
Registry のアドレスが registry.example.com:5000 であるとします。
sudo mkdir -p /etc/docker/certs.d/registry.example.com:5000
sudo cp root_ca.crt /etc/docker/certs.d/registry.example.com:5000/ca.crt
ディレクトリ名は、実際にアクセスする Registry のホスト名とポートに一致させる必要があります。デフォルトの HTTPS 443 ポートは通常省略できます。ca.crt は PEM 形式の CA 証明書にし、私鍵にしないでください。
確認：
docker login registry.example.com:5000
Ubuntu / Debian ホスト全体で信頼する
sudo cp root_ca.crt /usr/local/share/ca-certificates/my-root-ca.crt
sudo update-ca-certificates
Linux 上では、Docker は通常ホストのシステム CA 信頼ストアを使用します。通常 Docker を再起動する必要はありません。それでも有効にならない場合は、Docker のログと証明書設定を確認してから、再起動するかどうかを決めてください（再起動すると実行中のコンテナに影響する可能性があります）。
二、コンテナ内でプライベート CA を信頼する
ホストで CA を信頼していても、コンテナ内の curl、プログラム、またはランタイムが自動的に信頼するとは限りません。
Debian / Ubuntu ベースイメージの場合、Dockerfile 内で次のようなインストールを行う_ACTIVE_RECOMMENDATIONS_RECOMMENDED_INSTALLATION_IN_DOCKERFILE:
FROM ubuntu:24.04
RUN apt-get update && apt-get install -y ca-certificates \
&& rm -rf /var/lib/apt/lists/*
COPY root_ca.crt /usr/local/share/ca-certificates/root_ca.crt
RUN update-ca-certificates
サードパーティイメージを使用する場合も、Compose で証明書をマウントできます。
services:
app:
image: your-image:latest
volumes:
- ./root_ca.crt:/usr/local/share/ca-certificates/root_ca.crt:ro
ただし、マウントするだけでは自動的に有効にはなりません。コンテナ内で update-ca-certificates を実行する必要があり、イメージにこのコマンドが含まれていることと、信頼ストアへの書き込み権限があることも必要です。最小構成イメージや root 権限のないアプリケーションでは、優先してカスタムイメージを作成するか、アプリケーション自体がサポートする CA 設定を使用してください。
三、確認
HTTPS リクエストを行う必要がある環境で次を実行します。
curl -v https://service.example.com
信頼ストアの問題を調査する場合は、CA を明示して比較できます。
curl --cacert root_ca.crt https://service.example.com
CA を指定した接続が成功し、通常の接続が失敗する場合は、まずデフォルトの CA 信頼ストアを確認してください。証明書のドメイン名、有効期間、証明書チェーンも正しい必要があります。Java など、一部のランタイムには独立した信頼ストアがある場合があります。
CA の秘密鍵を Docker やコンテナにコピーしないでください。また、
insecure-registriesやcurl -kを使用して TLS 検証をスキップすることも推奨しません。