はじめに
本ドキュメントの目的
本書は、AWS S3へアクセスする際に発生する「SSL証明書検証エラー」について、原因と対処法を分かりやすくまとめたものです。AWS CLIやPythonのboto3、Dockerコンテナ内での証明書設定、大容量ファイルのアップロード時に出る特殊なエラーまで網羅的に扱います。実例と手順を重視し、現場で再現しやすい情報を提供します。
対象読者
- AWSを利用している開発者・運用担当者
- S3と連携するアプリケーションを作るエンジニア
- Dockerや証明書周りでトラブルシューティングが必要な方
本書で扱うポイント
- エラー発生時の確認手順（ログ、環境変数、設定ファイル）
- 一時的な回避方法と正しい恒久対策（CA証明書の配置や設定）
- DockerやAirbyteなどのOSS環境での実務的な設定例
注意事項
SSL検証を単純に無効にする方法は短期的に楽ですが、推奨しません。安全な通信を保ちつつ、正しい証明書の導入を優先して説明します。
AWS CLI SSL証明書検証エラーの問題報告
問題の概要
GitHubの報告では、AWS CLIで一部コマンド実行時にSSL検証エラーが発生します。例: aws ec2 describe-instances を実行すると「certificate verify failed: unable to get local issuer certificate」と表示されます。
再現手順（例）
- aws sso login を実行 — 成功する
- aws s3 ls を実行 — 成功する
- aws ec2 describe-instances を実行 — 「certificate verify failed」エラーが出る
- –no-verify-ssl を付けると ec2 や sts は成功する
影響範囲
aws ec2 や aws sts など一部API呼び出しのみ失敗し、SSOログインやS3は影響を受けません。業務でEC2情報取得やトークン検証ができなくなる恐れがあります。
疑われる原因
証明書バンドルの不正設定が疑われます。環境変数 HTTP_PROXY、HTTPS_PROXY、AWS_CA_BUNDLE の値が影響している可能性があります。プロキシでSSLを中継している環境や、誤ったCAファイルを指定した場合に発生しやすいです。
初期対処案
- 環境変数を確認: echo $AWS_CA_BUNDLE など
- AWS CLIのバージョン確認: aws –version
- 指定されたCAバンドルを開いてルート証明書が含まれるか確認
- プロキシがいる場合はプロキシ設定を一時無効化して試す
- –no-verify-ssl で一時回避し、根本原因を調査する
問題の切り分けにはログや環境情報が役立ちます。
Boto3 APIを使用したSSL検証失敗エラー
現象と原因
Palantir Foundry経由でboto3を通してS3互換APIへアクセスすると「certificate verify failed: unable to get local issuer certificate」が出る場合があります。これはシステムがサーバー証明書の発行元（中間CAやルートCA）をローカルで見つけられず、証明書の信頼性を検証できないために発生します。
再現コード例
import boto3
sess = boto3.Session()
client = sess.client('s3', endpoint_url='https://s3.example.com')
client.list_buckets()
上記でエラーが出ることがあります。
対処法（推奨）
1) CA証明書を指定する: verifyパラメータにCAバンドルのパスを渡します。
client = sess.client('s3', endpoint_url='https://s3.example.com', verify='/path/to/ca.pem')
2) certifiを使う（一般的なCAが必要な場合）:
import certifi
client = sess.client(..., verify=certifi.where())
3) OSまたはコンテナの信頼ストアにCAを追加する: Debian系ならupdate-ca-certificatesで導入します。
一時的な回避（注意）
verify=FalseでSSL検証を無効化できますが、セキュリティリスクが高いため本番では避けてください。
Palantir/コンテナ環境の注意点
実行環境にCAファイルが含まれていないケースが多いです。イメージにCAを組み込むか、ジョブ実行時にマウントしてverifyで指定してください。
Airbyte OSS環境でのカスタムCA証明書設定
問題の原因と概要
Docker上のAirbyte OSSでS3ソースをテストするとSSL検証エラーが出ることがあります。多くの場合、社内プロキシ経由で自己署名や社内発行のCAを使っているため、コンテナ内にそのCAが登録されていないことが原因です。AWS SDKは環境変数AWS_CA_BUNDLEでカスタムCAを参照できます。
設定手順（簡潔）
- ホストにCA証明書（.pem）を準備します。読み取り権限を付けてください。
- docker-compose.ymlでAirbyteのコネクタを実行するコンテナに証明書をマウントします。通常はworkerやscheduler相当のコンテナです。
- 同じコンテナに環境変数AWS_CA_BUNDLEを設定し、コンテナ内の証明書パスを指定します。したがって接続処理はそのCAを使って検証します。
- Airbyteを再起動して、S3ソースの接続テストを実行します。
docker-composeの例
services:
airbyte-worker:
image: airbyte/worker:latest
environment:
- AWS_CA_BUNDLE=/etc/ssl/certs/custom-ca.pem
volumes:
- ./certs/custom-ca.pem:/etc/ssl/certs/custom-ca.pem:ro
プロキシ利用時の注意点
プロキシ経由の場合はHTTP_PROXY/HTTPS_PROXYも同じコンテナに設定してください。証明書の場所と環境変数が一致していることを確認します。
動作確認
接続テストでエラーが消えれば成功です。まだエラーが出る場合は、コンテナに入ってopenssl s_clientやcurlで証明書チェーンを確認してください。
大容量ファイルアップロード時のSSL検証エラー
問題の概要
AWS CLIで500GBをS3にアップロードするときに、SSL検証エラー（”EOF occurred in violation of protocol”）が発生します。小容量ファイルは成功するのに大容量のみ失敗し、–no-verify-sslを付けても直らない状況です。
考えられる原因
- 長時間の接続でTLSセッションが途中切断される（プロキシやロードバランサのアイドルタイムアウト）。
- クライアント側のライブラリで大きなストリーム処理中にTLSハンドシェイクや再ネゴシエーションで問題が起きる。
- ネットワークの断続的な切断やMTUやパケット断片化の影響。
- CLIの実装や依存ライブラリ（Pythonのopensslやs3transfer）が大容量で不安定になる。
優先対応（実践的な手順）
- AWS CLI v2へ移行する：v2は高速な転送ライブラリ（CRTベース）を取り入れており、大容量で安定することが多いです。まずは小さいテストから導入を確認してください。
- マルチパートアップロードを明示的に使う：大きなファイルを分割して並列で送ると途中切断の影響が減ります。aws s3 cpは一定以上で自動的に分割しますが、パラメータでチャンクサイズや同時接続数を調整できます。
- タイムアウトと再試行の調整：CLIやOS側のソケットタイムアウトを長めに設定してみてください。長時間かかる転送では有効です。
- S3 Transfer Accelerationの検討：アップロード距離やネットワーク経路が原因の場合、加速を使うと安定することがあります。
- デバッグログを収集：awsコマンドに–debugを付けてエラーの前後ログを確認します。TLSで切断されているタイミングやHTTPステータスを確認してください。
追加の確認項目
- プロキシや社内ネットワーク機器のセッションタイムアウト設定を確認する。
- 他の手段（curlやopenssl s_client）で長時間ストリームが維持できるか試す。
- ネットワーク断続が疑われる場合は小さなマルチパートを並列で送り、再現性を確かめる。
ログ取得の例
- aws s3 cp largefile s3://bucket/ –debug
- curlでの挙動確認や、openssl s_clientでTLS接続を検査する
以上を順に試すことで原因を絞り、最終的にはCLI v2やマルチパート／転送加速を組み合わせると高確率で改善します。
