■ はじめに
前回は、SSLインスペクションで証明書がどのように扱われるかを説明しました。
- プロキシが証明書を再発行する
- 企業内CAを信頼することで通信が成立する
ここまでは理解できても、実務ではこんな問題にぶつかります。
■ よくある現象
- ブラウザ → 正常に通信できる
- curl → 失敗する
- Python → 失敗する
👉 同じHTTPS通信なのに結果が違う
■ 原因①：企業内CAを信頼していない
SSLインスペクション環境では、
👉 企業内CAが信頼されていることが前提
です。
ブラウザはOSの証明書ストアを利用するため、
👉 自動的に企業CAを信頼していることが多い
一方で、
- Python
- 一部のCLIツール
は独自の証明書ストアを使うことがあります。
■ 具体例（Python）
Pythonではよくこのエラーが出ます。
ssl.SSLCertVerificationError: certificate verify failed
これは
👉 企業CAを知らないため検証に失敗している
■ 対処
- 企業CAを明示的に指定する
- certifiの証明書ストアに追加する
- 環境変数でCAを指定する
■ 原因②：証明書の構造が“簡略化”されている
ここから少し踏み込みます。
SSLインスペクションで生成される証明書は、
👉 本物の証明書より簡略化されていることがある
■ AKI（Authority Key Identifier）とは
証明書には、発行者を特定するための情報が入っています。
そのひとつが
👉 AKI（Authority Key Identifier）
です。
これはざっくり言うと
👉「この証明書はどのCAによって発行されたか」を示す情報
■ 何が問題になるのか
一部のプロキシ製品では、
👉 AKIが含まれていない証明書を生成することがある
■ なぜそれで困るのか
昔はこれでも問題ありませんでした。
しかし最近は事情が変わっています。
■ Pythonの証明書検証は厳しくなっている
最近のPython（およびOpenSSL）は、
👉 証明書チェーンの検証をより厳密に行う
ようになっています。
そのため：
- AKIが無い
- チェーンが曖昧
といった証明書は
👉 検証に失敗することがある
■ その結果起きること
- ブラウザ → 通る（寛容 or OS依存）
- Python → 落ちる（厳格）
👉 この差がトラブルの原因になる
■ 対処パターン
状況によっていくつか現実的な対応があります。
① 正攻法
- 企業CAを正しく設定する
👉 本来あるべき対応
② Pythonのバージョンを下げる
- 古いPythonでは証明書検証が比較的緩い
- AKIが無い証明書でも通るケースがある
👉 どうしても動かしたい場合の現実解
ただし注意点：
- セキュリティ的には推奨されない
- 将来的に動かなくなる可能性がある
■ まとめ
- Pythonだけ通信失敗することがある
- 原因は企業内CA or 証明書構造
- SSLインスペクションの影響を受けている可能性が高い
- 特にAKIの有無で挙動が変わることがある