TLS エラーが社内 VPN だけで起きるとき：正しいトラストストアを直す

Go のビルドも Composer のインストールも Python クライアントも、家ではすべて動き、社内 VPN の中ではすべて失敗します。このパターンが語っているのは経路のことであり、アプリケーションのことではありません。トンネル上の何かが、プロセスが見る証明書チェーンを変えたか、チェーンが届く前にハンドシェイクをリセットしたかです。二つの障害はターミナルでは似て見えますが、まったく別の対応を必要とします。

三つのメッセージ、三つの仕組み

x509 certificate signed by unknown authority というエラーは、チェーンは構築されたがそのルートがそのプロセスが使うトラストストアに無いことを意味します。self-signed certificate in certificate chain というエラーは通常、検査プロキシが自分の証明書で応答したことを意味し、それは実行環境が認識しないチェーンです。ハンドシェイク中の SSL EOF は、使える証明書が送られる前に接続が閉じられたことを意味し、それはClientHello を拒否する中間装置であって、信頼の問題ではまったくありません。

安全でないフラグを足すと三つのメッセージは消えますが、傍受はそのまま残り、本物の攻撃者を捕まえるはずの検証まで外してしまいます。

そのプロセスが実際に読むバンドルを見つける

Windows のストアに入れた社内ルートは、システムストアを参照するブラウザーと .NET アプリを直します。しかし、独自の CA バンドルを持つコンテナ内で動くビルドには何の効果もなく、certifi を使う Python プロセスや同梱のリストを使う Node プロセスにも効果はありません。Go はバイナリが動く環境のシステムプールを読むので、見るのはコンテナであってノート PC ではありません。だから同じ一台が、動くブラウザーと失敗するビルドツールを同時に生み出します。

仮定せずにツールに尋ねてください。python3 -c "import ssl; print(ssl.get_default_verify_paths())" は Python が参照するファイルを出力し、node -e "console.log(process.env.NODE_EXTRA_CA_CERTS)" は上書きがすでに設定されているかどうかを示します。コンテナの場合は、ビルドが実際に使う環境であるイメージの中で同じ確認を実行してください。

ビルドが動く場所にルートを一つ入れる

検査ルートを PEM ファイルとして IT から受け取り、信頼する前に別の経路で指紋を確認します。Debian 系のイメージでは /usr/local/share/ca-certificates/ にコピーして update-ca-certificates を実行し、RHEL 系のイメージは、ファイルを /etc/pki/ca-trust/source/anchors/ に置いてから update-ca-trust を使います。コンテナのビルドでは、失敗するコマンドの前にこれらの手順を入れて、依存関係のインストールより上にレイヤーをキャッシュさせます。

ローカルの devcontainer なら、他の誰も再現できない個人用イメージに焼き込むのではなく、PEM をマウントして起動時に同じ更新コマンドを実行します。独自のバンドルを同梱するツールにはそれぞれ文書化された上書きが必要で、pip には証明書の設定があり、npm には cafile の設定があり、その他のほとんどは標準の環境変数を受け付けます。

これはどの証明書でも受け入れることとは違います。検査を行う側から得た特定のルートを 一つの環境に足すだけで、他のどのチェーンでも検証は有効なままです。検査ルートも他の CA と同じように更新されるので、どのファイルをいつ追加したか、いつ期限が切れるかを記録してください。

証明書より先にハンドシェイクが死ぬとき

何も提示されないなら、トラストストアを変えても意味がありません。同じリクエストをトンネルありとなしで比べ、次に openssl s_client -connect host:443 -servername host -showcerts でチェーンを直接調べます。VPN の外では完了し中ではリセットされる接続は、中間装置によるポリシー判断であり、対処は別の証明書ではなくそのホストの例外です。パッケージレジストリや API エンドポイントを無改変で通すよう依頼してください。

ツールが VPN を迂回するようにトンネルを分割すると、その通信の検査は避けられますが、ポリシーに違反する可能性があり、ツールが信頼できるようになるわけでもありません。

ツールごとに結果を書き残す

バイナリ、それが読む信頼ファイル、関係する環境変数、承認された例外を並べた短いメモがあれば、次の人は診断をまるごと省けます。メモは、変わったのはノート PC であることはほとんどないので、ノート PC ごとではなくツールごとに保ってください。

そしてチケットでは、特定の社内ルートを入れたことと検証を切ったことを二つの文に分けてください。サポート作業なのは片方だけです。