断続的なTLSハンドシェイク障害を引き起こす中間証明書の欠落を特定、診断、および修正する方法を学びます。
最も巧妙なネットワーク障害の1つは、Webサイトは自分のラップトップで完全に正常に読み込まれるのに、APIクライアント、モバイルアプリ、またはバックエンドのWebhookが、信頼できない証明書エラーで失敗する場合に発生します。これは、不完全な証明書チェーンの特徴です。
特定のクライアントタイプからのトラフィックが消えるまで、すべてが正常に見えます。これが正確に理由を分解し、それを証明する方法を見てみましょう。
TLS証明書を購入すると、デバイスのトラストストアに存在するルート認証局（CA）によって直接署名されることはほとんどありません。代わりに、ルートキーを保護するために中間CAによって署名されます。
クライアントはこの中間CAについて知らないため、TLSの仕様では、ハンドシェイク中サーバーが中間証明書を付加することが要求されています。サーバーをリーフ証明書だけで設定した場合、クライアントは信頼できるルートへのパスを構築できません。
チェーンが壊れているのに、なぜChromeはまだ緑色の南京錠を表示するのでしょうか？最新のWebブラウザは、以前にアクセスしたサイトからの中間証明書をキャッシュし、「AIA Fetching」を利用して欠落している連鎖証明書をその場でダウンロードします。
ただし、プログラム形式のクライアント（Axiosスクリプト、curl、Javaバックエンドなど）には、この贅沢はありません。彼らは、サーバーが送信したものを正確に評価します。中間が欠落している場合、ハンドシェイクは 'unable to get local issuer certificate' ですぐに失敗します。
チェーンが壊れていないことを証明するには、ブラウザのキャッシュが邪魔にならないようにサーバーに問い合わせる必要があります。opensslを使用してチェーンのシーケンスを検査します：
openssl s_client -showcerts -connect yourapi.com:443
出力の「Certificate chain」ブロックを確認してください。証明書が1つしか表示されない場合（depth=0）、サーバーの設定が間違っています。正常なチェーンは次のようになります：
Certificate chain 0 s:/CN=yourapi.com i:/C=US/O=Let's Encrypt/CN=R3 1 s:/C=US/O=Let's Encrypt/CN=R3 i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
ここに、ほとんどの監視設定の死角があります。内部システムは、外部のエンドポイントに対して生のプログラム形式クライアントをシミュレーションすることがあまりありません。
これを防ぐには、厳格なSSL検証を強制する明示的な合成監視が必要です。Heimdall Observerのようなプラットフォームを利用することで、インフラストラクチャのフルチェーンペイロードを継続的に評価できます。
DNS、ネットワーク、そしてアプリケーションが到達可能かどうかを決定する見えない層に焦点を当てたインフラストラクチャエンジニア。
