この内容は古いバージョンです。最新バージョンを表示するには、戻るボタンを押してください。
バージョン:4
ページ更新者:atom
更新日時:2026-10-07 08:54:15

タイトル: curl: (51) SSL: certificate subject name '～' does not match target host name '～'
SEOタイトル: curl: (51) SSL: certificate subject name '～' does not match

この記事の要点
  • curl の SSL: certificate subject name does not match target host name
  • 原因: サーバ証明書の CN / SAN に接続先ホスト名が含まれていない
  • URLのIP・ホスト名が証明書の対象に合わない場合に発生。IP用SANがあればIPでも検証できる
  • 対処: 証明書の SAN に合うホスト名でアクセス / 証明書を更新 / -kは修復ではなく検証無効化。通常は使用しない

 

エラー内容

タイトルの(51)は旧curlでの表示です。現行curlでは証明書の名前不一致も(60)として出る場合があるため、番号だけでCA信頼の問題と区別しないでください。エラー本文と証明書を確認します。

curl: (51) SSL: certificate subject name '～' does not match target host name '～'

curl でHTTPS接続したとき、サーバー証明書の CN (Common Name) または SAN (Subject Alternative Name) に、接続先ホスト名が含まれていない場合に発生する SSL 検証エラーです。証明書のドメインと接続先のドメインが一致しないことを意味します。

発生条件 / 原因

  • 証明書がそのホスト名向けに発行されていない — 例: example.com 用証明書を api.example.com で使っている
  • IPアドレスで直接アクセスしている — https://192.168.0.10/ など。証明書にそのIPアドレスのSANがなければ不一致になる
  • 証明書のSANが古い — ドメイン追加後に証明書を更新していない
  • 自己署名証明書／社内CA — 発行元が未信頼の問題と、ホスト名不一致の問題は別。社内CAでも対象ホスト名が必要
  • SNI（Server Name Indication）を解釈できないクライアントで、共有ホストの別ドメイン証明書が返っている

対処法

1. 接続先ホスト名と証明書の中身を確認

まず証明書のCN/SANに、接続したいホスト名が含まれているかを確認します。

$ openssl s_client -connect example.com:443 -servername example.com < /dev/null | openssl x509 -noout -subject -ext subjectAltName

Subject の CN と X509v3 Subject Alternative Name に対象ホスト名が無ければ、証明書側の問題です。

2. 正しいホスト名で接続する

証明書が example.com 用なら、IPやサブドメインではなく example.com でアクセスします。

$ curl https://example.com/path

3. IP接続だが特定ホストで証明書を検証したい場合

--resolve オプションを使うと、ホスト名を保ったままIPを指定できます。

$ curl --resolve example.com:443:192.168.0.10 https://example.com/path

4. 開発・検証用に検証をスキップ（本番禁止）

-k または --insecure オプションでSSL検証を無視できます。セキュリティ上、開発／検証以外では使わないでください。

$ curl -k https://192.168.0.10/path

5. 証明書側を直す（サーバー管理者側）

  • 必要なホスト名を SAN に追加して証明書を再発行する
  • Let's Encrypt なら certbot で対象ドメインを追加して再発行
  • ワイルドカード証明書（*.example.com）に切り替える

社内CAは検証を残して信頼させる

信頼できる管理者から取得したCA証明書を指定する例です。CAへの信頼を追加しても、URLと証明書のホスト名不一致は直りません。エラー先から取得した証明書を確認せず信頼対象へ追加しないでください。

curl --cacert company-ca.pem https://api.example.com/path

ワイルドカード*.example.comは通常api.example.comのような1階層を対象にし、example.com自体やa.b.example.comを自動で含むものではありません。必要なSANを確認してください。

注意点

  • -k は暗号化はされるが認証は無い状態になり、中間者攻撃の検知ができなくなる
  • 本番ではホスト名と証明書を必ず一致させる。AWS ALB/CloudFront などのCDN/LBを通すときも証明書のSANに注意
  • 旧(51)は現在の(60)へ統合されています（curl 7.62.0以降）。(60)だからCAだけの問題とは判断せず、名前不一致・信頼・期限などエラー本文を確認すること

安全な確認順

  1. curl --versionで版とTLSバックエンドを確認します。
  2. URLのホスト名と実際に返された証明書のSANを比較します。
  3. DNSだけを固定したい場合は、本文の--resolve例でURLの名前とSNIを維持します。
  4. 名前が正しければCAへの信頼・証明書チェーン・期限を確認します。
  5. -kを付けずに再実行し、証明書検証を通ることを確認します。

-kの例は検証を無効にする動作の説明として残しています。隔離したダミーデータの切り分けでも慎重に扱い、認証情報・Cookie・機密データを送信しないでください。

公式資料: curlエラー番号の統合、TLS検証とCA指定、ホスト名とIPの検証、curlオプション（2026年10月確認）。