同じ ca.crt ファイル名でも証明書が違う：何を比べるか

二つのプロファイルはどちらも ca.crt という名前のファイルを持っていますが、一方のトンネルは上がり、もう一方はチェーンエラーで失敗します。二つのファイルを並べて開いても決着することはほとんどなく、検証を無効にすると間違った方向に決着します。エラーが本当に問うているのはもっと狭いことです：各プロセスはどの証明書を信頼アンカーとして読み込むのか、そして両者は同じオブジェクトなのか。まずこれに答えれば、残りの診断に方向がつきます。ファイル名はパッケージのラベルであり、プロファイルに書かれたパスも権威ではないので、すべてはプロセスが実際に何を読むかにかかっています。

クライアントが実際に読み込む証明書を見つける

OpenVPN は認証局を二つの形式で受け取り、形式によってどのバイトが重要かが決まります。プロファイルは ca で外部ファイルを指すことも、証明書をプロファイル内の <ca> ブロックに埋め込むこともできます。両方がある場合は埋め込まれたブロックが優先され、プロファイルの隣のファイルは決して開かれません。

失敗しているプロファイルを読み、何かを比較する前にどちらの形式を使っているかを突き止めます。隣のディレクトリや、もう一方のプロファイルが入っていたパッケージから取ったコピーは、このプロセスが何を信頼しているかについて何も語りません。設定内のパスも同じで、クライアントが起動された場所を基準に解決され、それが常に今見ているディレクトリとは限りません。フォルダではなくプロファイルを読んでください。

証明書は公開鍵、サブジェクトと発行者、有効期間、そしてそのすべてに対する署名という内容で識別されます。同じバイトを持つ二つのファイルは名前が何であれ同じ証明書であり、同じ名前の二つのファイルは無関係な認証局かもしれません。名前はパッケージのラベルであり、身元ではありません。

openssl で両方のコピーのフィンガープリントを取る

フィンガープリントは証明書の DER エンコーディングに対するハッシュで、署名が対象とする形式なので、改行やヘッダーのテキストに影響されません。各ファイルについて計算すれば、コロンで区切られた十六進文字列が二つ得られ、一致するかしないかがわかります。比較の問いに答えるために証明書のほかの部分を読む必要はありません。

openssl x509 -in /etc/openvpn/office/ca.crt -noout -fingerprint -sha256
openssl x509 -in ~/profiles/lab-ca.pem -noout -fingerprint -sha256

openssl をプロファイル自体に向けるのは魅力的ですが、ファイル内で最初に現れる証明書ブロックを読むうえ、プロファイルは通常 <cert> を <ca> より前に持っています。認証局のブロックを抽出し、クライアントが実際に使うそのコピーのフィンガープリントを取ってください。

sed -n '/^<ca>$/,/^<\/ca>$/p' office.ovpn | sed '1d;$d' > /tmp/office-ca.pem
openssl x509 -in /tmp/office-ca.pem -noout -fingerprint -sha256

フィンガープリントが同一なら信頼の素材は同じで、チェーンエラーには別の原因があり、それは別の調査です。フィンガープリントが違えば証明書が違うということで、次の節はそこから始まります。

攻撃を疑う前に不一致を読む

フィンガープリントが違うということは、証明書が違うというだけのことです。再発行、ローテーション、名前を変えた認証局、古いバンドルはどれも、まったく正当な経緯を持つ別のファイルを生みます。どれが配備に属するかは運用者または配備記録への問いであり、ファイルの更新時刻への問いではありません。アーカイブはタイムスタンプをコピーするので、新しいファイルが自動的に正しいアンカーとは限りません。

自分自身に署名するルートは正常なので、それを見つけても問題の証拠にはなりません。検証者の仕事は、サーバー証明書から渡されたアンカーまでの経路を構築することであり、チェーンエラーは通常、その経路を完成できなかったことを意味します。

失敗しているプロファイルのアンカーが、配備が今も発行している認証局かどうかを確認します。フィンガープリントが配備記録のどれとも一致しないなら、プロファイルが単に古いのであり、クライアント側の調整では直りません。

検証を切らずに信頼を修復する

短期的な修正は、検証を無効にするか、チェーン内のすべての証明書をアンカーとして追加することです。どちらもメッセージを消し、どちらも今後クライアントが受け入れるサーバーを変えてしまいます。検証を再び有効にし、意図したアンカーを導入して、もう一度テストしてください。

チェーンが構築されるようになったのに別のエラーが出るなら、それは前進です：名前の検証、有効期限、失効はそれぞれ別のメッセージを持つ別のチェックです。フィンガープリントの組と元のエラーテキストをチケットに一緒に残し、次の担当者がどのアンカーを読み込み、どれを期待していたかを見られるようにします。フィンガープリントの組は引き継ぎメモに貼れるほど小さいので、次に起きたときは半日ではなく五分で済みます。

正しい認証局は、プロファイルを届けたのと同じ認証済みチャネルを通じて入手してください。サブジェクトが見覚えがあるからという理由でサーバーから証明書を引き抜くのは別の行為であり、クライアントが信頼する範囲を静かに広げてしまいます。