企業のプロキシ環境で「aws configure sso」を実行すると、原因不明のSSLエラーで止まってしまうことがあります。これは単なる設定ミスではなく、ブラウザとコマンドラインツールでプロキシの扱いが異なること、そしてAWS CLI(CLI:Command Line Interface)のSSO関連コマンドに特有の既知の制限が重なって起きる現象です。この記事では、その仕組みと対処法を整理します。

Contents
  1. 何が起きているのか：エラーの正体
  2. 原因①：ブラウザとCLIでプロキシの扱いが違う
  3. 原因②：企業プロキシのSSLインスペクション
  4. さらに厄介な点：SSOコマンド特有の既知の制限
  5. 対処法
  6. Windowsでルートcertificateを確認・エクスポートする方法
  7. 中小企業・大企業のIT担当者が知っておくべきこと
  8. よくある質問
  9. 参考にした主な調査・資料
  10. まとめ

何が起きているのか：エラーの正体

企業のネットワークでaws configure ssoやaws sso loginを実行すると、次のようなエラーで処理が止まることがあります。

[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed

ブラウザでAWSのマネジメントコンソールには問題なくアクセスできるのに、AWS CLIだけがエラーになる、というケースが典型的です。

原因①：ブラウザとCLIでプロキシの扱いが違う

別記事「プロキシサーバーとは？VPNとの違いを非エンジニア向けにわかりやすく解説」で紹介したとおり、企業のWindows端末では、PACファイルによってブラウザの通信が自動的に適切なプロキシへ振り分けられていることがよくあります。aws configure ssoは認可のために一時的にブラウザを開きますが、その後のトークン取得・ポーリング処理はAWS CLI自身が直接HTTPS通信を行います。このCLI側の通信は、Windowsが管理するPACファイルの設定を自動的には参照しません。プロキシ経由で通信させるには、HTTPS_PROXYのような環境変数を別途、明示的に設定する必要があります。

原因②：企業プロキシのSSLインスペクション

多くの企業プロキシ（前述の記事で紹介したi-FILTERやZscaler、Netskopeなどのセキュアウェブゲートウェイ製品）は、通信内容を検査するために「SSLインスペクション」を行っています。これは、通信の途中でいったん暗号化を解除し、社内のCA（認証局）が発行した独自の証明書で再度暗号化し直す仕組みです。ブラウザは多くの場合、会社が配布するグループポリシー等を通じてこの社内CA証明書をあらかじめ信頼するよう設定されていますが、AWS CLIはこの社内CA証明書を標準では信頼していません。そのため、SSLインスペクションを行うプロキシを経由した瞬間に証明書エラーが発生します。

さらに厄介な点：SSOコマンド特有の既知の制限

通常のAWS CLIコマンドであれば、--ca-bundleオプションやAWS_CA_BUNDLE環境変数で、信頼させたい証明書ファイルを指定することで解決できます。しかし、AWS CLIの開発リポジトリで報告されている既知の問題として、aws configure ssoとaws sso loginの2つのコマンドは、これらの設定を無視するという制限があります。この2つのコマンドは、AWS CLIのインストール先に同梱されているcacert.pemという証明書バンドルファイルのみを参照する仕様になっているためです。つまり、他のコマンドで使える通常の解決方法が、SSO関連のコマンドには通用しないという点に注意が必要です。

対処法

  1. cacert.pemファイルの場所を特定する：Windowsであれば、AWS CLI v2のインストール先（例：C:Program FilesAmazonAWSCLIV2配下）にあるbotocore関連フォルダの中にcacert.pemが存在します
  2. 社内プロキシのルートCA証明書をエクスポートする：情報システム部門に依頼するか、ブラウザの証明書ストアからPEM形式でエクスポートします
  3. cacert.pemの末尾に、そのルートCA証明書の内容を追記する：既存の内容を消さず、追記する形にします
  4. HTTPS_PROXY環境変数を設定する：PACファイルが指し示しているのと同じプロキシアドレス・ポートを、CLIからも明示的に使えるようにします

なお、cacert.pemを直接編集する方法は、AWS CLIのアップデート時にファイルが上書きされ、設定が失われる可能性がある点には注意してください。アップデート後にSSOログインが再びエラーになった場合は、同じ手順をやり直す必要があります。

Windowsでルートcertificateを確認・エクスポートする方法

社内のIT部門にすぐ確認できない場合、Windows端末で自分自身が信頼しているルート証明書を確認することもできます。

  1. Win + Rでcertmgr.mscと入力して実行し、証明書マネージャーを開く
  2. 「信頼されたルート証明機関」フォルダの中から、会社名やセキュリティ製品名（Zscaler、Netskope等）を含む証明書を探す
  3. 該当の証明書を右クリックし、「すべてのタスク」→「エクスポート」を選択
  4. 「Base64 encoded X.509（.CER）」形式を選んでエクスポートする（これがPEM形式に相当します）

複数の候補が見つかった場合は、どれが実際にSSLインスペクションに使われている証明書かをIT部門に確認することをおすすめします。誤った証明書を追加しても効果がないだけでなく、不要な証明書を信頼させることになるため注意が必要です。

中小企業・大企業のIT担当者が知っておくべきこと

この問題から得られる教訓は、AWS CLIに限った話ではありません。クラウドサービスのCLIツールやAPIクライアントは、ブラウザとは別の通信経路・別のプロキシ設定の仕組みを使っていることが多く、「ブラウザでは繋がるのにCLIだけエラーになる」という現象は、他のクラウドベンダーのCLIツールでも起こり得ます。企業のネットワーク担当者は、ブラウザ向けのPAC/WPAD設定だけでなく、開発者やIT担当者が使うCLIツール向けに、環境変数ベースのプロキシ設定や、社内CA証明書の配布方法もあわせて整備しておく必要があります。

よくある質問

Q. 「–no-verify-ssl」オプションで証明書検証を無効化すればよいのでは？

技術的には可能ですが、おすすめしません。証明書検証を無効化すると、正規のAWSサーバーかどうかを確認する仕組み自体が失われ、中間者攻撃などのリスクに対して無防備になります。前述のとおり、SSOコマンドはこのオプション自体を無視する既知の制限もあるため、根本的な解決にはなりません。

Q. 社内にプロキシ管理の担当者がいない場合、どうすればよいですか？

まずは自社が使っているセキュリティ製品（Webフィルタリングサービス等）のベンダーに、SSLインスペクションを行っているか、社内CA証明書をどう入手できるかを確認するとよいでしょう。契約しているITベンダーやSIerに相談するのも一つの方法です。

Q. この問題はAWS CLI以外でも起きますか？

起こり得ます。Pythonの標準的なHTTPライブラリを使うツールや、他のクラウドベンダーのCLIツールでも、企業プロキシのSSLインスペクション環境下で同様の証明書エラーが報告されています。原因の構造は基本的に共通しています。

参考にした主な調査・資料

まとめ

企業プロキシ環境でAWS CLIのSSOコマンドがSSLエラーになるのは、ブラウザとCLIでプロキシの扱いが異なること、企業プロキシのSSLインスペクションによって証明書が差し替わること、そしてSSO関連コマンド特有の既知の制限が重なって起きる現象です。原因を切り分けたうえで、社内CA証明書をCLIに正しく認識させることが、根本的な解決につながります。

Post Views: 108
AWS クラウド セキュリティ対策 ネットワーク プロキシ 中小企業DX 技術解説