はい、承知いたしました。curl コマンド実行時に発生するエラー unable to get local issuer certificate の解決方法に関する詳細な解説記事を、約5000語で記述します。

`curl` エラー「unable to get local issuer certificate」の完全ガイド：原因、診断、そして解決策

はじめに

インターネット上のリソースにアクセスする際に、コマンドラインツールである curl は非常に便利で強力なツールです。Webページの取得、APIへのデータ送信、ファイルのダウンロードなど、多岐にわたる用途で利用されています。しかし、インターネット上の多くのリソースがHTTPS（HTTP Secure）を使用しているため、curl を使用する際にSSL/TLS証明書に関するエラーに遭遇することがあります。

その中でも、特に頻繁に見られるエラーの一つが unable to get local issuer certificate です。このエラーは、curl が接続しようとしているサーバーから提供されたSSL/TLS証明書の信頼性を検証できない場合に発生します。このエラーに直面すると、目的のリソースにアクセスできず、作業が中断されてしまいます。

この記事では、curl の unable to get local issuer certificate エラーについて、その根本的な原因から、様々な診断方法、そして具体的な解決策に至るまで、網羅的かつ詳細に解説します。この記事を読むことで、エラーの発生メカニズムを理解し、自身で問題を解決するための知識とスキルを身につけることができます。

SSL/TLSの基本と証明書チェーン

unable to get local issuer certificate エラーを理解するためには、まずSSL/TLSプロトコルと、その根幹をなすデジタル証明書の仕組みについて基本的な知識を持つことが不可欠です。

SSL/TLSとは？なぜ重要なのか？

SSL（Secure Sockets Layer）およびその後継であるTLS（Transport Layer Security）は、インターネット上でデータを安全に送受信するための暗号化プロトコルです。WebサイトのHTTPS、メールのSMTPS、VPNなど、様々な通信で利用されています。

SSL/TLSが提供する主要な機能は以下の3つです。

暗号化（Encryption）: 通信内容を第三者に盗聴されないように暗号化します。これにより、機密情報（パスワード、クレジットカード情報など）が安全にやり取りできます。
認証（Authentication）: 接続相手が主張する通りの相手であることを確認します。特にサーバー認証は重要で、アクセスしようとしているWebサイトが本物であることを証明します。
改ざん検出（Integrity）: 送受信中にデータが改ざんされていないことを確認します。

curl がHTTPS接続を行う際には、このSSL/TLSプロトコルを使用してサーバーとの間で安全な通信チャネルを確立します。このプロセスの中で、サーバーは自身の身元を証明するためにSSL/TLS証明書をクライアント（curl）に提示します。

SSL/TLS証明書の役割

SSL/TLS証明書は、サーバーの公開鍵と、その公開鍵が特定の組織やドメインに属していることを証明する電子的な身分証明書です。証明書には、以下のような情報が含まれています。

主体者（Subject）: 証明書が発行された対象（ドメイン名、組織名など）。
発行者（Issuer）: 証明書を発行した認証局（CA）の名前。
公開鍵（Public Key）: サーバーの公開鍵。クライアントはこれで通信データを暗号化します。
有効期間（Validity Period）: 証明書が有効である期間。
署名（Signature）: 発行者であるCAが自身の秘密鍵で証明書全体に施した署名。クライアントはこの署名をCAの公開鍵で検証し、証明書が改ざんされていないか確認します。

認証局（CA）と信頼の連鎖

証明書の信頼性は、認証局（CA: Certificate Authority） と呼ばれる第三者機関によって保証されます。CAは、証明書の発行を専門に行う信頼された組織です。サーバー運営者は、証明書を取得する際にCAに申請を行い、身元確認などの審査を受けます。審査を通過すると、CAはそのサーバー運営者の公開鍵を含む証明書を発行し、自身の秘密鍵で署名します。

クライアント（ブラウザや curl）は、サーバーから受け取った証明書が信頼できるかどうかを検証します。この検証プロセスは、証明書チェーン（Certificate Chain） または 信頼のパス（Path of Trust） と呼ばれる階層構造をたどることで行われます。

証明書チェーンは、通常以下の3つのレベルで構成されます。

エンドエンティティ証明書（End-Entity Certificate）: サーバー自身に発行された証明書（例: www.example.com 用の証明書）。これはチェーンの最下位にあたります。
中間CA証明書（Intermediate CA Certificate）: ルートCAとエンドエンティティ証明書の間に位置するCAが発行した証明書。多くのCAは、セキュリティ上の理由から、自身の秘密鍵をオフラインで厳重に保管し、オンラインでの証明書発行には中間CAを使用します。
ルートCA証明書（Root CA Certificate）: 階層の最上位に位置するCAの証明書。これは自己署名証明書（自身が自身に署名した証明書）です。

クライアントは、サーバーから提供されたエンドエンティティ証明書の署名を、その証明書の発行者である中間CAの公開鍵で検証します。次に、その中間CA証明書の署名を、さらに上位の中間CA（あるいはルートCA）の公開鍵で検証します。このプロセスをたどり、最終的にチェーンの最上位にあるルートCA証明書にたどり着きます。

クライアントは、自身にあらかじめインストールされている、信頼できるルート証明書ストア（Trusted Root Certificate Store） に含まれるルートCA証明書と照合します。サーバー証明書チェーンの最上位のルート証明書が、クライアントの信頼ストアにあるルート証明書の一つと一致した場合、そのチェーン全体が信頼できると判断され、サーバー証明書は「検証済み」となります。

逆に、サーバー証明書チェーンをたどっても、クライアントの信頼ストアにあるルート証明書に到達できない場合、クライアントはその証明書チェーンを信頼できず、検証に失敗します。この失敗が、unable to get local issuer certificate エラーの主な原因となります。

`unable to get local issuer certificate` エラーが発生する原因

このエラーメッセージは、「ローカル（クライアント側）に、サーバー証明書の発行者（issuer）を検証するための証明書（通常は中間CAまたはルートCA）が見つからない、または取得できない」という意味です。具体的には、以下のような様々な原因が考えられます。

1. クライアント側の信頼されたルート証明書ストアが古い、または不完全

これは最も一般的な原因です。新しい認証局が登場したり、既存の認証局が証明書を発行する際に使用する中間CA証明書を変更したりすることがあります。しかし、クライアント（OSやアプリケーション）の信頼されたルート証明書ストアが最新の状態に更新されていない場合、新しい証明書チェーンの検証に必要な中間CA証明書やルートCA証明書が含まれていないため、チェーンの検証に失敗します。

2. サーバーが中間CA証明書を正しく提供していない（不完全なチェーン）

SSL/TLSハンドシェイクにおいて、サーバーは通常、自身の証明書だけでなく、その証明書に署名した中間CA証明書（またはチェーン全体）をクライアントに提供する必要があります。これにより、クライアントはチェーンをたどってルートCAまで検証できます。しかし、サーバーの設定ミスにより、エンドエンティティ証明書のみを提供し、必要な中間CA証明書を含めていない場合があります。この場合、クライアントは提供された証明書の署名者を検証しようとしますが、その署名者である中間CAの証明書をサーバーから受け取れないため、自身のストアから見つけようとします。もしクライアントのストアにその中間CA証明書が直接含まれていない場合（通常、中間証明書はストアには含まれず、ルート証明書のみが含まれます）、チェーンの検証パスが見つからず、エラーとなります。

3. クライアント側の証明書ストアが破損している、または構成が誤っている

ごく稀に、クライアント側のOSやアプリケーションが管理している信頼された証明書ストアファイル自体が破損したり、設定ファイルが誤っていたりする場合があります。これにより、正規のルート証明書が見つからなくなる可能性があります。

4. プロキシやファイアウォールがSSLトラフィックを傍受（SSLインスペクション）している

企業ネットワークなどで、セキュリティ対策としてSSL/TLSトラフィックを復号・検査（SSLインスペクションまたはSSL傍受）している場合があります。この場合、プロキシやファイアウォールはクライアントからの接続を終端し、サーバーとの間に新しいSSL/TLS接続を確立します。クライアントに対しては、プロキシやファイアウォールが独自の証明書を発行して提示します。この独自の証明書は、通常、そのプロキシ/ファイアウォールによって生成されたルートCA（または中間CA）によって署名されています。もしこのプロキシ/ファイアウォールのルートCA証明書が、クライアントの信頼されたルート証明書ストアに含まれていない場合、クライアントはその証明書を信頼できず、検証に失敗します。

5. サーバー証明書が自己署名証明書である

自己署名証明書は、認証局によって署名されたものではなく、証明書自体が自身の公開鍵で署名されたものです。これは、テスト環境や内部システムなどでよく使用されます。自己署名証明書は、信頼できる第三者による身元保証がないため、クライアントの信頼ストアにその証明書（またはその発行者）が明示的に追加されていない限り、デフォルトでは信頼されません。curl は、自己署名証明書を信頼できないと判断し、この unable to get local issuer certificate または類似のエラーを出すことがあります（ただし、多くの場合、自己署名証明書の場合は SSL certificate problem: self signed certificate という別のエラーになることが多いです）。しかし、チェーンが不完全である場合など、状況によってはこのエラーとして報告される可能性もあります。

6. クライアント側のSSLライブラリや設定の問題

curl は通常、システムにインストールされているSSL/TLSライブラリ（OpenSSL, NSS, Secure Transportなど）を使用します。これらのライブラリ自体に問題があったり、特定の環境変数や設定ファイルによって証明書の検索パスが誤っていたりする場合に、エラーが発生する可能性があります。

これらの原因を踏まえ、次にエラーの診断方法について解説します。

エラーの診断方法

unable to get local issuer certificate エラーが発生した場合、闇雲に解決策を試すのではなく、まずは原因を特定するための診断を行うことが重要です。以下の方法を試してみましょう。

1. `curl` コマンド自体による詳細な診断 (`-v` オプション)

curl に -v (verbose) オプションを付けて実行すると、通信の詳細なログが表示されます。これにより、SSL/TLSハンドシェイクの過程や、証明書の検証に関する情報が得られます。

bash curl -v https://example.com/resource

出力の中から、* SSL connection using... で始まる行以降に注目してください。特に、証明書の検証に関連するメッセージが表示されるはずです。

“`
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, unknown CA (560): <- これが出ているか確認
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

stopped the pause stream early
“`

-v 出力で unknown CA や unable to get local issuer certificate と明示的に表示されていることを確認します。また、サーバーが提示する証明書の詳細（発行者、有効期間など）も表示されることがあります。サーバーが提示する証明書チェーンに中間CA証明書が含まれているかどうかも、この出力から判断できる場合があります。

2. 対象のURLをブラウザで開いてみる

同じURLをWebブラウザ（Chrome, Firefox, Edgeなど）で開いてみてください。ブラウザも同様にSSL/TLS証明書の検証を行いますが、通常はより親切なエラーメッセージや警告を表示します。

ブラウザで問題なく開ける場合: これは、curl が使用している証明書ストア と、ブラウザが使用している証明書ストア が異なるか、あるいは curl が証明書を検索する際の設定に問題がある可能性が高いです。ブラウザはOS標準の証明書ストアを利用することが多いですが、curl はビルド方法やOSによって、独自のストアを使用したり、OSストアを利用したり、OpenSSLなどのライブラリの設定に従ったりします。
ブラウザでも証明書エラーが発生する場合: この場合、問題はクライアント側全体、あるいはサーバー側の設定に起因している可能性が高まります。ブラウザのエラーメッセージ（例: 「プライバシーエラー」「この接続はプライベートではありません」「無効な発行元」など）から、より具体的な原因（例: 証明書の有効期限切れ、ホスト名の不一致、信頼できないCA）が分かることがあります。ただし、自己署名証明書や信頼されていないCAによる証明書の場合、ブラウザは「続行」オプションを提示することがありますが、curl はデフォルトでは検証失敗で処理を中断します。

3. `openssl` コマンドを使った診断

openssl は、SSL/TLSに関する強力なコマンドラインツールです。これを使うと、サーバーから提供される証明書チェーンを直接取得し、検証することができます。

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

上記のコマンドを実行すると、サーバーとのSSL/TLS接続を試み、接続が成功した場合はサーバー証明書や中間証明書が表示されます。出力の最後に、検証結果が表示されます。

“`
… (証明書情報などがたくさん表示される) …

SSL handshake has read 3403 bytes and written 428 bytes
Verification error: unable to get local issuer certificate <- これを確認
Verify return code: 21 (unable to get local issuer certificate)

…
“`

Verify return code: 21 (unable to get local issuer certificate) または類似のエラーメッセージが表示されていれば、openssl も証明書チェーンを信頼できないと判断しています。

さらに詳細な情報を得るために、-showcerts オプションを付けて実行すると、サーバーが提供する証明書チェーン全体が表示されます。

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

出力される複数の証明書ブロック（-----BEGIN CERTIFICATE----- から -----END CERTIFICATE----- まで）を確認し、エンドエンティティ証明書、中間CA証明書が含まれているか、そして各証明書の Issuer と次の証明書の Subject が一致しているか（チェーンが繋がっているか）を確認します。Verify return code: 21 が出ているにも関わらず、openssl が表示するチェーンに中間証明書が含まれていない場合は、サーバー側が中間証明書を提供していない可能性が高いです。

4. ウェブベースのSSLチェッカーツールの利用

SSL LabsのSSL Server Test (https://www.ssllabs.com/ssltest/) のようなオンラインツールに問題のURLを入力すると、サーバーのSSL/TLS設定や証明書チェーンについて詳細な分析を行ってくれます。サーバーが中間証明書を正しく提供しているか（”Chain issues: Incomplete” などが表示されていないか）、証明書が有効期限内か、信頼されているCAによって発行されているかなどを確認できます。これにより、問題がサーバー側にあるのか、クライアント側にあるのかを切り分けるのに役立ちます。

5. システム上の証明書ストアの確認

クライアントOSが管理している信頼されたルート証明書ストアの内容を確認します。

Windows: certmgr.msc を実行します。「信頼されたルート認証機関」のストアを確認します。
macOS: キーチェーンアクセス (/Applications/Utilities/Keychain Access.app) を開きます。「システム」キーチェーンの「証明書」カテゴリを確認します。
Linux (Debian/Ubuntu): /etc/ssl/certs/ ディレクトリや update-ca-certificates コマンド関連の設定ファイルを確認します。
Linux (RHEL/CentOS): /etc/pki/tls/certs/ ディレクトリや update-ca-trust コマンド関連の設定ファイルを確認します。

特定のCA証明書がストアに含まれているか、ファイルが正しく存在するかなどを確認できます。

これらの診断ステップを踏むことで、エラーがクライアント側の証明書ストアの問題なのか、サーバー側のチェーン設定の問題なのか、あるいはプロキシなどのネットワーク環境の問題なのか、おおよその見当をつけることができます。

解決策

診断によって原因が特定できたら、それに応じた解決策を適用します。ここでは、様々な原因に対応する具体的な解決策を詳細に解説します。

1. クライアント側の証明書ストアを更新・修復する

クライアント側の信頼されたルート証明書ストアが古いことが原因である場合、これを最新の状態に更新するのが最も一般的で推奨される解決策です。

OSのアップデート: OSのアップデートには、信頼されたルート証明書のリスト更新が含まれていることが多いです。Windows Update, macOSのソフトウェアアップデート、Linuxディストリビューションのパッケージマネージャー（apt upgrade, yum update, dnf upgrade など）を実行して、OSを最新の状態に保ちましょう。
ca-certificates パッケージの更新 (Linux): 多くのLinuxディストリビューションでは、信頼されたCA証明書は ca-certificates という名前のパッケージで管理されています。このパッケージを最新版に更新することで、証明書ストアが更新されます。
- Debian/Ubuntu: sudo apt update && sudo apt install --reinstall ca-certificates
- RHEL/CentOS/Fedora: sudo yum update ca-certificates または sudo dnf update ca-certificates
- 更新後、システムによっては証明書ストアを再構築するコマンドが必要な場合がありますが、多くはパッケージ更新時に自動実行されます。手動で実行する場合は、Debian/Ubuntu系では sudo update-ca-certificates、RHEL/CentOS/Fedora系では sudo update-ca-trust extract を試してみてください。
手動でのルート証明書の追加 (非推奨): 特定の理由でOS全体のストアを更新できない場合や、独自のCA証明書を追加する必要がある場合は、手動で証明書ファイルを取得し、システムやアプリケーションの証明書ストアに追加することも可能です。ただし、誤った証明書を追加するとセキュリティリスクを招くため、信頼できるソースからのみ取得し、細心の注意を払って行ってください。追加方法はOSやアプリケーションによって異なります（後述の「OS別の証明書ストア管理」を参照）。
証明書ストアファイルの破損: もし証明書ストアファイルが破損している可能性がある場合は、OSのシステムファイルチェッカーを実行したり、ca-certificates パッケージを再インストールしたりすることで修復できる場合があります。

2. `curl` コマンドで信頼する証明書を指定する

システム全体の証明書ストアを更新できない場合や、特定の証明書のみを信頼したい場合は、curl コマンド実行時に信頼する証明書を指定するオプションを使用できます。

`--cacert [ファイルパス]` オプション

このオプションは、証明書の検証に使用する信頼されたCA証明書（またはCA証明書が複数含まれるバンドルファイル）のパスを指定します。指定されたファイルに含まれるCA証明書のみが信頼されます。

bash curl --cacert /path/to/your/ca-bundle.pem https://example.com/resource

CA証明書バンドルファイルの入手:
- 多くのLinuxシステムでは、/etc/ssl/certs/ca-certificates.crt や /etc/pki/tls/certs/ca-bundle.crt といったパスに、一般的なCA証明書をまとめたファイルが用意されています。
- Mozillaが公開している信頼されたルート証明書リストを基にしたPEM形式のバンドルファイルがよく利用されます。これは、curlの配布元などから入手できます（例: https://curl.se/docs/caextract.html）。
- もし特定のCA証明書ファイルが必要な場合は、そのCAのWebサイトからPEM形式でダウンロードできることがあります。
カスタムバンドルファイルの作成: 複数のCA証明書ファイルを一つのファイルにまとめたい場合は、各証明書ファイル（PEM形式、-----BEGIN CERTIFICATE----- から -----END CERTIFICATE----- までを含む）をテキストエディタで連結して新しいファイルを作成します。

--cacert オプションは、システムストアに問題がある場合や、特定の環境下で異なるCAリストを使用したい場合に非常に有効です。

`--capath [ディレクトリパス]` オプション

このオプションは、信頼されたCA証明書ファイルが含まれるディレクトリのパスを指定します。curl は、指定されたディレクトリ内の証明書ファイルを検索して検証に使用します。ただし、このオプションを使用する場合、ディレクトリ内の証明書ファイルはOpenSSLが特定のハッシュ値で参照できるように配置され、シンボリックリンクが作成されている必要があります。これは c_rehash コマンド（または openssl rehash）を使用して設定します。

“`bash

証明書ファイルが /path/to/certs ディレクトリにある場合

cd /path/to/certs
c_rehash . # または openssl rehash .
curl –capath /path/to/certs https://example.com/resource
“`

この方法は、個別の証明書ファイルを多数管理する場合に便利ですが、セットアップに手間がかかります。多くの場合、--cacert オプションでバンドルファイルを指定する方が手軽です。

`CURLOPT_CAPATH` および `CURLOPT_CAINFO` (プログラムからの使用)

curl をライブラリとしてプログラムから利用する場合（例: C, PHP, Pythonなどのバインディング）、CURLOPT_CAPATH または CURLOPT_CAINFO オプションを使用して、信頼する証明書のパスを指定できます。これらはそれぞれコマンドラインオプションの --capath および --cacert に対応します。

環境変数による設定 (`SSL_CERT_FILE`, `SSL_CERT_DIR`)

curl が使用するSSL/TLSライブラリ（特にOpenSSL）は、環境変数 SSL_CERT_FILE や SSL_CERT_DIR を参照して、信頼されたCA証明書のパスを見つけることがあります。

SSL_CERT_FILE: --cacert オプションと同様に、CA証明書バンドルファイルのパスを指定します。
SSL_CERT_DIR: --capath オプションと同様に、CA証明書が含まれるディレクトリのパスを指定します。

これらの環境変数を設定することで、毎回コマンドラインオプションを指定することなく、curl や他のOpenSSLを使用するプログラムで同じ証明書設定を共有できます。

bash export SSL_CERT_FILE=/path/to/your/ca-bundle.pem curl https://example.com/resource # これで指定した証明書ファイルが使われる

3. サーバー側の問題の解決（不完全なチェーン）

診断の結果、サーバーが中間CA証明書を正しく提供していない（不完全なチェーン）ことが原因であると判明した場合、クライアント側でできる直接的な解決策は限られます。

サーバー管理者に連絡する: 最も良い解決策は、対象のサーバーの管理者に連絡し、SSL/TLS証明書の設定が正しいか（特に中間証明書が正しく配信されているか）確認してもらうことです。サーバー側の設定を修正してもらうのが、根本的な解決となります。
クライアント側での一時的な回避策: サーバー管理者がすぐに対応できない場合、クライアント側で一時的に回避する方法がいくつか考えられますが、これらはあくまで暫定的なものであり、セキュリティリスクを伴う可能性もあります。
- 必要な中間証明書を自分で取得し、--cacert オプションで指定する: openssl s_client -connect ... -showcerts などを使用してサーバーから提供される証明書を取得し、不足している中間証明書を特定します。その中間証明書ファイルを入手し、信頼できるルート証明書バンドルと連結したファイルを --cacert で指定します。ただし、中間証明書を安全に入手できる保証はなく、手間もかかります。
- 証明書検証を無効にする (--insecure または -k): これは最終手段であり、絶対に避けるべきです。 証明書検証を無効にすると、curl はサーバー証明書が偽物であるかどうかにかかわらず接続を続行します。これにより、中間者攻撃（Man-in-the-Middle Attack）のリスクが極めて高まります。特に、機密情報を送受信する接続でこのオプションを使用することは絶対に避けてください。デバッグ目的など、セキュリティリスクを完全に理解し、かつそのリスクが許容される限定的な状況でのみ 使用してください。
“`bash

!!! 危険なオプションです !!!

curl –insecure https://example.com/resource

または

curl -k https://example.com/resource
“`

4. プロキシ/ファイアウォールの問題の解決（SSLインスペクション）

プロキシやファイアウォールによるSSLインスペクションが原因の場合、クライアント側の証明書ストアに、その傍受に使用されているプロキシ/ファイアウォールのルートCA証明書を追加する必要があります。

プロキシ/ファイアウォールのルートCA証明書を取得する: 組織のIT部門などに問い合わせて、SSLインスペクションに使用されているルートCA証明書ファイル（通常はDERまたはPEM形式）を入手します。
クライアントの信頼された証明書ストアに追加する: 入手した証明書ファイルを、クライアントOSまたは curl が使用する証明書ストアに追加します。追加方法はOSによって異なります（後述の「OS別の証明書ストア管理」を参照）。これにより、プロキシ/ファイアウォールが発行した証明書がクライアントに信頼されるようになります。
プロキシ設定の確認: curl が正しくプロキシを使用するように設定されているかも確認します。環境変数（HTTPS_PROXY, HTTP_PROXY, ALL_PROXY など）や、curl オプション（-x, --proxy）でプロキシ設定が可能です。

5. 自己署名証明書への対応

対象のサーバーが自己署名証明書を使用している場合、デフォルトでは信頼されません。

正式な証明書を使用する: 可能であれば、Let’s Encryptのような無料のCAや、商用のCAから正式な証明書を取得してサーバーに設定するのが最善です。
自己署名証明書を信頼ストアに追加する: 自己署名証明書をクライアント側に配布し、信頼された証明書としてストアに追加します。これにより、その特定の自己署名証明書のみが信頼されるようになります。追加方法はOSによって異なります。
--cacert で自己署名証明書ファイルを指定する: 自己署名証明書ファイル（PEM形式）をローカルに保存し、--cacert オプションでそのファイルを指定します。

bash curl --cacert /path/to/self-signed.pem https://example.com/resource
--insecure を使用する: 繰り返しますが、これは非常に危険なオプションです。 自己署名証明書であるという事実のみを無視して接続したい場合に使用できますが、中間者攻撃のリスクを伴います。デバッグや、信頼できるネットワーク内で一時的に使用する場合に限定すべきです。

6. クライアント側のSSLライブラリや設定の問題

ごく稀に、クライアント側のSSLライブラリ（OpenSSLなど）のインストールに問題があるか、システム設定が原因で証明書ファイルが見つからない場合があります。

SSLライブラリの再インストール: システムにインストールされているSSLライブラリを再インストールしてみてください。
証明書の検索パスを確認する: 使用しているSSLライブラリ（特にOpenSSL）が、どのディレクトリやファイルを信頼されたCA証明書として参照するように設定されているかを確認します。これは、ライブラリのコンパイル時の設定や、環境変数、OpenSSLの設定ファイル（/etc/ssl/openssl.cnf など）によって決まります。openssl version -d コマンドで設定ディレクトリを確認できる場合があります。

`curl` オプションの詳細

解決策で触れた curl のオプションについて、もう少し詳しく解説します。

`--cacert <file>`

指定された file に含まれるCA証明書のみを信頼して検証を行います。

file はPEM形式である必要があります。DER形式の証明書の場合は、OpenSSLなどを使用してPEM形式に変換する必要があります (openssl x509 -inform der -in certificate.cer -outform pem -out certificate.pem)。
file は単一の証明書でも、複数の証明書を連結したバンドルファイルでも構いません。複数の証明書を含む場合、各証明書は -----BEGIN CERTIFICATE----- と -----END CERTIFICATE----- で囲まれている必要があります。
このオプションを指定した場合、システムデフォルトの証明書ストアは使用されないことがあります（SSLライブラリの実装による）。したがって、通常は一般的なルートCA証明書をまとめたバンドルファイルを指定するのが推奨されます。
環境変数 SSL_CERT_FILE も同様の役割を果たします。

`--capath <directory>`

指定された directory 内の証明書を信頼して検証を行います。

directory 内の証明書ファイルは、OpenSSLがハッシュ値で参照できるように配置されている必要があります。これは c_rehash または openssl rehash コマンドを使用して設定します。これらのコマンドは、ディレクトリ内のPEM形式の証明書ファイルごとにハッシュ値に基づいた名前のシンボリックリンクを作成します。
単一のファイルではなく、多数の個別ファイルを管理する場合に適しています。
環境変数 SSL_CERT_DIR も同様の役割を果たします。

`-k, --insecure`

SSL/TLS証明書の検証を完全に無効にします。

極めて危険なオプションです。 中間者攻撃が容易になります。
正当なサーバー証明書が提示されても、それが自己署名証明書であろうと、無効な証明書であろうと、期限切れであろうと、ホスト名が一致しなかろうと、curl は一切警告せず接続を続行します。
本番環境や機密情報を扱う接続では絶対に使用しないでください。
使用する際は、その危険性を十分に理解し、自己責任で行ってください。一時的なデバッグ目的や、完全に信頼できる閉じたネットワーク環境でのみ限定的に使用を検討できます。

その他の関連オプション

--cert <certificate file>: クライアント証明書を指定する場合に使用します（サーバー認証ではなくクライアント認証が必要な場合）。これ自体は unable to get local issuer certificate エラーの直接の原因ではありませんが、SSL/TLS接続に関連するオプションとして覚えておくと役立ちます。
--key <private key file>: クライアント証明書に対応する秘密鍵を指定する場合に使用します。
--ciphers <list of ciphers>: 使用する暗号スイートを指定します。証明書検証エラーとは直接関連しませんが、SSL/TLS接続の問題診断に使用されることがあります。

OS別の証明書ストア管理

クライアントOSが管理する信頼されたルート証明書ストアは、curl がデフォルトで使用する証明書の場所の一つです（curl のビルド方法や使用しているSSLライブラリに依存します）。OS別の管理方法を知っておくと、ストアの更新や手動での証明書追加を行う際に役立ちます。

Windows

Windowsでは、証明書は証明書ストアに保存されており、Microsoft Management Console (MMC) の証明書スナップイン（certmgr.msc）を使用して管理できます。

certmgr.msc を実行します。
左側のツリービューで「信頼されたルート認証機関」を展開し、「証明書」を選択します。
ここに表示される証明書が、システムが信頼するルート証明書です。
新しい信頼されたルート証明書を追加するには、右クリックメニューから「すべてのタスク」->「インポート」を選択し、証明書インポートウィザードに従います。インポート先として「信頼されたルート認証機関」ストアを選択します。
証明書を削除するには、対象の証明書を選択して右クリックし、「削除」を選択します。

通常、Windows Updateによってこのストアは自動的に最新に保たれます。

macOS

macOSでは、証明書はキーチェーンに保存されており、「キーチェーンアクセス」アプリケーション (/Applications/Utilities/Keychain Access.app) を使用して管理します。

「キーチェーンアクセス」を起動します。
左側のサイドバーで「システム」キーチェーンを選択します。
下のカテゴリで「証明書」を選択します。
ここにシステムが信頼する証明書が表示されます。
新しい証明書を追加するには、ファイルをキーチェーンアクセスウィンドウにドラッグ＆ドロップするか、メニューから「ファイル」->「項目の読み込み」を選択します。証明書を読み込む際に、どのキーチェーン（通常は「システム」）に保存するかを選択し、信頼設定を確認・変更できます。
証明書を削除するには、対象の証明書を選択して右クリックし、「削除」を選択します。

通常、macOSのソフトウェアアップデートによってシステムキーチェーン内の証明書は自動的に更新されます。

Linux (Debian/Ubuntu系)

Debian、Ubuntu、Linux Mintなどのシステムでは、信頼されたCA証明書は主に /etc/ssl/certs/ ディレクトリに保存されています。証明書は個別の .crt ファイルとして存在し、OpenSSLなどが参照しやすいようにハッシュ値に基づいたシンボリックリンクが作成されます。

信頼された証明書バンドルファイル: /etc/ssl/certs/ca-certificates.crt がよく使用されます。
CA証明書の管理ツール: ca-certificates パッケージと update-ca-certificates コマンドを使用します。
ストアの更新: sudo apt update && sudo apt install --reinstall ca-certificates を実行します。
手動での証明書追加:
1. 追加したい証明書ファイル（PEM形式、拡張子は .crt が一般的）を /usr/local/share/ca-certificates/ ディレクトリに配置します。
2. sudo update-ca-certificates コマンドを実行します。これにより、/etc/ssl/certs/ ディレクトリにシンボリックリンクが作成され、ca-certificates.crt ファイルが更新されます。
証明書の削除: /usr/local/share/ca-certificates/ ディレクトリから証明書ファイルを削除し、sudo update-ca-certificates --fresh を実行します。

Linux (RHEL/CentOS/Fedora系)

RHEL、CentOS、Fedora、Rocky Linux、AlmaLinuxなどのシステムでは、信頼されたCA証明書は主に /etc/pki/tls/certs/ ディレクトリに保存されています。

信頼された証明書バンドルファイル: /etc/pki/tls/certs/ca-bundle.crt がよく使用されます。
CA証明書の管理ツール: ca-certificates パッケージと update-ca-trust コマンドを使用します。
ストアの更新: sudo yum update ca-certificates または sudo dnf update ca-certificates を実行します。
手動での証明書追加:
1. 追加したい証明書ファイル（PEM形式またはDER形式、拡張子は .crt, .pem, .cer など）を /etc/pki/ca-trust/source/anchors/ ディレクトリに配置します。
2. sudo update-ca-trust extract コマンドを実行します。これにより、システム全体の信頼ストア（/etc/pki/tls/certs/ca-bundle.crt など）が更新されます。
証明書の削除: /etc/pki/ca-trust/source/anchors/ ディレクトリから証明書ファイルを削除し、sudo update-ca-trust extract を実行します。

これらのOS固有の管理方法を理解しておくことで、診断や解決策の適用がスムーズに行えます。

セキュリティに関する考慮事項

unable to get local issuer certificate エラーの解決において、セキュリティは最も重要な考慮事項です。安易な解決策が、深刻なセキュリティリスクを招く可能性があります。

`--insecure` の危険性

前述の通り、--insecure オプションはSSL/TLS証明書の検証を完全に無効にします。これは、通信相手が正当なサーバーであるという保証を完全に放棄することを意味します。

中間者攻撃（Man-in-the-Middle Attack）: 攻撃者は、クライアントと正規のサーバーの間に入り込み、偽の証明書を提示できます。--insecure オプションを使用しているクライアントは、この偽の証明書を受け入れてしまい、攻撃者は通信内容を盗聴したり改ざんしたりすることが可能になります。
信頼できないサーバーへの接続: 証明書検証は、接続しようとしているサーバーが本当に目的のサーバーであることを確認する手段です。検証を無効にすると、誤って悪意のあるサーバーに接続してしまうリスクが高まります。

したがって、--insecure は絶対に本番環境や機密情報を扱う場面で使用しないでください。デバッグや、完全に信頼できる閉じた環境でのみ、そのリスクを十分に理解した上で使用してください。

信頼できない証明書をストアに追加することのリスク

自己署名証明書や、信頼できないソースから入手した証明書をシステムの信頼されたルート証明書ストアに手動で追加することは、潜在的なリスクを伴います。もし追加した証明書が悪意のあるものである場合、その証明書を使用して行われる偽のWebサイトやサービスの証明書を、システム全体が信頼してしまう可能性があります。証明書は、必ず信頼できる認証局から発行されたものか、自身が完全に管理・信頼できるシステムで生成されたもののみを使用・追加してください。

常に証明書検証を有効にすることの重要性

SSL/TLS証明書検証は、安全なインターネット通信の基盤です。この検証プロセスを有効にしておくことで、接続相手の正当性を確認し、盗聴や改ざんから通信を保護できます。エラーが発生した場合は、--insecure で一時的に回避するのではなく、根本的な原因（証明書ストアの不備、サーバー設定ミス、プロキシ設定など）を特定し、検証を有効にしたまま問題を解決することが極めて重要です。

証明書失効リスト (CRL) および OCSP

証明書は、有効期間内であっても、秘密鍵の漏洩などの理由で失効することがあります。SSL/TLSライブラリは、通常、証明書失効リスト (CRL) や Online Certificate Status Protocol (OCSP) を使用して、サーバーが提示した証明書が失効していないかを確認します。curl には --ssl-no-revoke オプションがありますが、これはこの失効チェックを無効にするものであり、セキュリティリスクを高めるため、通常は使用すべきではありません。unable to get local issuer certificate エラーとは直接関連しませんが、証明書検証の完全性を保つ上で重要な概念です。

まとめ

curl コマンドで発生する unable to get local issuer certificate エラーは、SSL/TLS証明書の信頼チェーンをクライアント側で確立できない場合に発生します。その原因は多岐にわたりますが、最も一般的なのはクライアント側の信頼されたルート証明書ストアが古いか、サーバー側が中間CA証明書を正しく提供していないことです。

このエラーに効果的に対処するためには、まず診断が不可欠です。curl -v や openssl s_client、オンラインのSSLチェッカーツールなどを活用して、エラーの具体的な原因を特定しましょう。

特定された原因に応じて、以下の解決策を優先順位を付けて試すことをお勧めします。

クライアントOSの信頼されたルート証明書ストアを最新に更新する。 （Windows Update, macOSアップデート, Linuxの ca-certificates パッケージ更新など）
サーバー管理者に連絡し、証明書チェーンが正しく設定されているか確認してもらう。 （特に中間証明書の配信設定）
プロキシ/ファイアウォールによるSSLインスペクションが原因の場合は、そのCA証明書をクライアントの信頼ストアに追加する。
curl の --cacert オプションを使用して、信頼できるCA証明書バンドルファイルを明示的に指定する。 （例: /etc/ssl/certs/ca-bundle.crt やMozilla提供のバンドル）
自己署名証明書の場合は、その証明書を信頼ストアに追加するか、--cacert で指定する。
クライアント側のSSLライブラリや設定に問題がないか確認・修復する。

絶対に避けるべき解決策は、--insecure または -k オプションを使用して証明書検証を無効にすることです。 これは通信のセキュリティを著しく損ない、中間者攻撃のリスクに晒されます。デバッグ目的以外で安易に使用しないでください。

多くの場合、OSや ca-certificates パッケージを最新の状態に保つことで、このエラーは解決します。それでも解決しない場合は、サーバー側の設定やネットワーク環境（プロキシなど）に問題がある可能性が高いと考えられます。

この記事が、curl の unable to get local issuer certificate エラーに効果的に対処するための一助となれば幸いです。SSL/TLS通信の安全性を確保することは、インターネットを安全に利用する上で非常に重要です。常に証明書検証を有効にし、信頼できる証明書のみを使用することを心がけましょう。

付録

よくある質問 (FAQ)

Q: --insecure を使えばエラーは消えるのに、なぜ使ってはいけないのですか？
- A: エラーが消えるのは、証明書の検証自体をスキップするからです。これは問題の根本的な解決ではなく、単に問題を隠蔽しているに過ぎません。検証をスキップすると、通信相手が本物であるという保証がなくなり、中間者攻撃などのセキュリティリスクに無防備になります。機密情報が盗まれたり、通信内容が改ざんされたりする危険性があります。
Q: 信頼するCA証明書バンドルファイルはどこで入手できますか？
- A: 多くのLinuxシステムでは /etc/ssl/certs/ca-certificates.crt や /etc/pki/tls/certs/ca-bundle.crt にあります。または、curlの公式ドキュメント (https://curl.se/docs/caextract.html) からMozilla提供のリストに基づいたPEM形式のバンドルファイルを入手できます。これは最も一般的な方法です。
Q: サーバー管理者ですが、不完全なチェーンをどう修正すれば良いですか？
- A: ウェブサーバー（Apache, Nginxなど）の設定ファイルで、エンドエンティティ証明書だけでなく、中間CA証明書も含むように設定する必要があります。通常、証明書ファイルやバンドルファイルを指定する設定項目（例: Apacheの SSLCertificateFile に中間証明書とサーバー証明書を連結したファイル、または SSLCertificateChainFile、Nginxの ssl_certificate に中間証明書とサーバー証明書を連結したファイル）を確認し、正しく設定してください。SSL Labsなどのオンラインツールで設定を確認できます。
Q: プロキシのCA証明書をクライアントに追加する方法が分かりません。
- A: 組織のITサポートに問い合わせてください。プロキシ/ファイアウォール製品によっては、クライアントPCに自動的に証明書を配布する仕組みがあったり、手動でインストールするための手順書が用意されていたりします。勝手に追加せず、必ず管理者やIT部門の指示に従ってください。
Q: 特定の内部サイトにアクセスする際にだけエラーが出ます。どうすれば良いですか？
- A: その内部サイトが自己署名証明書を使用しているか、組織内の独自のCAを使用している可能性が高いです。IT部門に、そのサイトで使用されている証明書チェーンの情報（特にルートCAや中間CA証明書）を提供してもらい、クライアントの信頼ストアに追加する必要があるか確認してください。

curl エラー「unable to get local issuer certificate」の完全ガイド：原因、診断、そして解決策

はじめに

SSL/TLSの基本と証明書チェーン

SSL/TLSとは？ なぜ重要なのか？

SSL/TLS証明書の役割

認証局（CA）と信頼の連鎖

unable to get local issuer certificate エラーが発生する原因

1. クライアント側の信頼されたルート証明書ストアが古い、または不完全

2. サーバーが中間CA証明書を正しく提供していない（不完全なチェーン）

3. クライアント側の証明書ストアが破損している、または構成が誤っている

4. プロキシやファイアウォールがSSLトラフィックを傍受（SSLインスペクション）している

5. サーバー証明書が自己署名証明書である

6. クライアント側のSSLライブラリや設定の問題

エラーの診断方法

1. curl コマンド自体による詳細な診断 (-v オプション)

2. 対象のURLをブラウザで開いてみる

3. openssl コマンドを使った診断

4. ウェブベースのSSLチェッカーツールの利用

5. システム上の証明書ストアの確認

解決策

1. クライアント側の証明書ストアを更新・修復する

2. curl コマンドで信頼する証明書を指定する

--cacert [ファイルパス] オプション

--capath [ディレクトリパス] オプション

証明書ファイルが /path/to/certs ディレクトリにある場合

CURLOPT_CAPATH および CURLOPT_CAINFO (プログラムからの使用)

環境変数による設定 (SSL_CERT_FILE, SSL_CERT_DIR)

3. サーバー側の問題の解決（不完全なチェーン）

!!! 危険なオプションです !!!

または

4. プロキシ/ファイアウォールの問題の解決（SSLインスペクション）

5. 自己署名証明書への対応

6. クライアント側のSSLライブラリや設定の問題

curl オプションの詳細

--cacert <file>

--capath <directory>

-k, --insecure

その他の関連オプション

OS別の証明書ストア管理

Windows

macOS

Linux (Debian/Ubuntu系)

Linux (RHEL/CentOS/Fedora系)

セキュリティに関する考慮事項

--insecure の危険性

信頼できない証明書をストアに追加することのリスク

常に証明書検証を有効にすることの重要性

証明書失効リスト (CRL) および OCSP

まとめ

付録

よくある質問 (FAQ)

関連ツール

コメントする 返信をキャンセル

`curl` エラー「unable to get local issuer certificate」の完全ガイド：原因、診断、そして解決策

SSL/TLSとは？なぜ重要なのか？

`unable to get local issuer certificate` エラーが発生する原因

1. `curl` コマンド自体による詳細な診断 (`-v` オプション)

3. `openssl` コマンドを使った診断

2. `curl` コマンドで信頼する証明書を指定する

`--cacert [ファイルパス]` オプション

`--capath [ディレクトリパス]` オプション

`CURLOPT_CAPATH` および `CURLOPT_CAINFO` (プログラムからの使用)

環境変数による設定 (`SSL_CERT_FILE`, `SSL_CERT_DIR`)

`curl` オプションの詳細

`--cacert <file>`

`--capath <directory>`

`-k, --insecure`

`--insecure` の危険性

コメントする返信をキャンセル