「certificate verify failed」の解決 - CA証明書とSSL検証

2026-06-05 読了時間: 約11分 難易度: 中級

この記事で解決できること

• 「certificate verify failed」「unable to get local issuer certificate」の 本当の原因 が分かる
• openssl s_client で 3 系統のどれが原因か を即切り分けできる
• CA 証明書・チェーン不備・時刻ズレを 正しい手順で直せる

certificate verify failed とは何か？

結論: クライアントがサーバ証明書を、信頼するルート CA まで辿れなかった状態。証明書が「偽物」とは限らず、検証材料が足りていないことが多い。

TLS 接続では、クライアントはサーバから受け取った証明書を ルート CA まで連鎖（チェーン）させて検証 する。このチェーンが繋がらない、あるいは有効期限・ホスト名が一致しないと検証は失敗する。

ツールによってメッセージは異なるが、中身は同じ検証失敗である。

curl: (60) SSL certificate problem: unable to get local issuer certificate

ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1006)

まず原因を切り分けるには？

結論: openssl s_client で実際のチェーンと Verify return code を見る。番号がどの系統の問題かを一意に指す。

ブラウザや curl の前に、まず生の TLS ハンドシェイクを観測する。

openssl s_client -connect example.com:443 -servername example.com

-servername は SNI を指定する（バーチャルホスト環境で必須）。出力末尾の Verify return code を確認する。

チェーンの中身は次でも確認できる。

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer

notBefore=Apr  1 00:00:00 2026 GMT
notAfter=Jun 30 23:59:59 2026 GMT
subject=CN=example.com
issuer=CN=Example Intermediate CA

CA証明書が古い・欠けている場合は？

結論: クライアント側の CA バンドルを更新する。Debian 系は ca-certificates を入れて update-ca-certificates を実行する。

Verify return code: 20 で、サーバ証明書自体は正規 CA 発行の場合、ローカルの信頼ストアが古い。

sudo apt update
sudo apt install --reinstall ca-certificates
sudo update-ca-certificates

Updating certificates in /etc/ssl/certs...
3 added, 0 removed; done.

社内 CA など独自のルート証明書を信頼させたい場合は、PEM 形式（拡張子 .crt）を所定ディレクトリに置いて再生成する。

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

RHEL / CentOS / Fedora 系の場合

ディレクトリとコマンドが異なる。

sudo cp company-root-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

サーバの証明書チェーンが不完全な場合は？

結論: Verify return code: 21 はサーバ側の設定ミス。中間証明書を含む fullchain を配信させるのが正攻法。クライアント側で回避すべきではない。

s_client の出力で Certificate chain に サーバ証明書しか並んでいない（中間 CA が無い）なら、サーバが中間証明書を送っていない。多くのブラウザは中間証明書をキャッシュ・補完するため「ブラウザでは見えるのに curl で落ちる」が起きる。

正しい対処は サーバ側で fullchain を配信 すること。

• Nginx: ssl_certificate にサーバ証明書 + 中間証明書を連結した fullchain.pem を指定する
• Apache: SSLCertificateFile に fullchain を指定（または SSLCertificateChainFile で中間証明書を指定）
• Let's Encrypt（certbot）: cert.pem ではなく fullchain.pem を使う

検証はブラウザではなく外部チェッカー（SSL Labs 等）か、別ホストからの openssl s_client で行う。

システム時刻のズレが原因の場合は？

結論: certificate has expired / not yet valid が出て証明書自体は有効なら、システム時刻を疑う。timedatectl で同期状態を確認する。

証明書の有効期限（notBefore / notAfter）は システム時刻と比較 して検証される。コンテナや復帰直後の VM で時刻が大きくズレると、有効な証明書でも expired や not yet valid と判定される。

timedatectl

               Local time: Fri 2026-06-05 12:00:00 UTC
           Universal time: Fri 2026-06-05 12:00:00 UTC
          System clock synchronized: yes
                NTP service: active

System clock synchronized: no や明らかな日付ズレがあれば NTP を整える。

sudo timedatectl set-ntp true

時刻同期の詳細は サーバ時刻ズレの対処 を参照。

自己署名・期限切れ証明書への対処は？

結論: 自己署名（return code 19/18）は、その CA を明示的に信頼ストアへ追加する。検証無効化は一時切り分けに限定する。

開発環境や社内プロキシでは自己署名証明書が使われる。正攻法は その証明書（または発行元 CA）を信頼ストアに追加 すること（前述の update-ca-certificates 手順）。

どうしても一時的に検証をスキップする場合のみ、影響範囲を理解した上で使う。

# 一時切り分け限定。常用しない
curl -v https://internal.example.com   # まず原因を見る
curl -k https://internal.example.com   # 検証スキップ（危険）

ツール別の対処（curl / Python / git）

結論: OS の CA を直しても Python だけ失敗するのは certifi 別バンドルが原因。ツールごとに参照する CA ストアが違う点を押さえる。

curl / wget

OS の CA ストアを参照する。一時的に特定 CA を指定する場合:

curl --cacert /path/to/ca.pem https://example.com
wget --ca-certificate=/path/to/ca.pem https://example.com

Python（requests / urllib）

requests は OS ではなく 同梱の certifi バンドル を参照する。OS の CA を更新しても直らない典型例。

# requests が見ている CA バンドルの場所を確認
python3 -c "import certifi; print(certifi.where())"

特定の CA を使わせる場合は環境変数で指定する。

export REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt
export SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt

git

# 特定リポジトリのみ CA を指定
git config http.sslCAInfo /path/to/ca.pem

# 環境変数でも指定可能
export GIT_SSL_CAINFO=/path/to/ca.pem

git config --global http.sslVerify false は検証を完全に無効化するため使わない。

やってはいけないこと

結論: 検証の恒久無効化、無関係な CA の大量追加、時刻を手動固定するなどの「とりあえず通す」対処は、後で必ず事故になる。