curlのエラー60「SSL certificate problem: unable to get local issuer certificate」を修正する方法

beginner🔒 SSL/TLS2026-04-20| Linux (Ubuntu, Debian, CentOS, Alpine), macOS, Windows (WSL/Git Bash)

Error Message

curl: (60) SSL certificate problem: unable to get local issuer certificate
#curl#wget#ssl#証明書#ca-bundle#linux

何が起きているのか?ツールをダウンロードしようとしたり、APIエンドポイントを叩こうとしたりすると、データの代わりに「Error 60」で終わるテキストの壁が表示されることがあります。システムがそのサーバーの身元を確認できないため、接続が即座に停止します。これは、傍受されたトラフィックから保護するためのセキュリティ上の障壁ですが、ローカルの設定の問題で発生することがよくあります。

curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it.

なぜCurlがエラーを出すのか多くの場合、問題の原因はいくつかの共通の要因に集約されます。ツール(curlwget)は、信頼できる認証局(CA)のリスト、つまり「信頼の源泉(source of truth)」を探していますが、それが見つからない状態です。

  • 古いCA証明書: システムの証明書ストアが何年も更新されていません。Let's Encryptのような新しい認証局を認識できていません。
  • 最小限の環境: alpine:latestのような軽量のDockerイメージでは、サイズを節約するためにca-certificatesパッケージが省略されていることがよくあります。
  • 企業内の「中間者」: 多くのオフィスでは、ウェブサイトの本物の証明書を会社所有のものに差し替えるファイアウォール(Zscalerなど)を使用しています。システムに会社のルート証明書がない場合、エラーが発生します。
  • パスの不一致: ツールは/etc/ssl/certsを探していますが、ディストリビューションによっては別の場所に保存されています。

方法1:システム証明書ストアを更新するシステムの信頼できる認証局の「アドレス帳」を更新するのが、通常は最も手っ取り早い解決策です。これにより、OSは最新のグローバルプロバイダーのリストをダウンロードします。

Ubuntu / Debian```

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


### CentOS / RHEL 7 & 8 / Fedora```
sudo yum update ca-certificates
# 新しいRHELベースのシステムの場合
sudo dnf upgrade ca-certificates
update-ca-trust extract

Alpine Linux (Docker)```

apk update apk add ca-certificates update-ca-certificates


## 方法2:CAバンドルを手動で指定するルート権限のない制限されたサーバーで作業している場合は、システムのストアを完全にバイパスできます。curlのメンテナから最新のバンドルを直接ダウンロードし、コマンドでそれを指定します。

- 最新のバンドルを取得する: ```
curl -O https://curl.se/ca/cacert.pem
  • --cacertフラグを付けてcurlを実行する: ``` curl --cacert cacert.pem https://example.com
もし**wget**を使用したい場合は、次の構文を使用します:

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


## 方法3:環境変数を設定するすべてのコマンドにフラグを入力するのは面倒です。代わりに、証明書の場所をグローバルにシェルに教えます。これは、CI/CDパイプラインや自動化スクリプトにおいて非常に便利です。

export CURL_CA_BUNDLE="/home/user/certs/cacert.pem" curl https://example.com


これを永続化するには、`~/.bashrc`または`~/.zshrc`ファイルの末尾にそのexport行を追加します。
## 方法4:企業のファイアウォール内での作業企業環境では、ファイアウォールがプロキシとして機能することがよくあります。トラフィックを傍受し、復号化してから、内部証明書を使用して再暗号化します。マシンの設定で、勤務先のルートCAを信頼するように設定する必要があります。

- ITチームに`.crt`または`.pem`のルート証明書を依頼します。
- 信頼済みフォルダに移動します: ```
sudo cp office-proxy-root.crt /usr/local/share/ca-certificates/
  • sudo update-ca-certificatesを実行してインデックスを作成します。

方法5:安全ではない「クイックフィックス」自己署名証明書を使用しているローカル開発サーバーなどで、とりあえず動かしたい場合があります。セキュリティを完全に無視するようにcurlに指示できます。警告:公開されているウェブサイトや本番コードでは決して使用しないでください。

# 短いフラグ
curl -k https://localhost:8080

# 長いフラグ
curl --insecure https://localhost:8080

# wgetの場合
wget --no-check-certificate https://localhost:8080

確認-vフラグを付けてcurlを実行し、ハンドシェイクが正常に完了するか確認します。出力の最後の方にある「SSL certificate verify ok」というメッセージを探してください。

curl -vI https://google.com

ターミナルで信頼チェーンを確認できるはずです:

* TLSv1.3 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384
* Server certificate:
*  subject: CN=*.google.com
*  issuer: C=US; O=Google Trust Services; CN=GTS CA 1C3
*  SSL certificate verify ok.

セキュリティを維持するために以下の3つの習慣で環境を健全に保ちましょう:

  • 自動更新: 毎週apt upgradeを実行して、CAストアを最新の状態に保ちます。
  • Dockerのベストプラクティス: 初期のビルドフェーズで、常にDockerfileにca-certificatesを追加してください。
  • 手動移動を避ける: /etc/ssl内のファイルを手動で移動しないでください。リンクを安全に管理するために、update-ca-certificatesユーティリティを使用してください。

Related Error Notes