リーフ証明書は有効、チェーンは期限切れ：深さを読む

サーバー証明書を確認すると、時計にはまだ数か月残っているのに、クライアントは期限切れのメッセージで接続を拒否します。あなたが読んだ日付はリーフのもので、不満は経路のもっと深いところにあるかもしれません。検証はチェーンをたどり、このたどりで選ばれたどの証明書も、それ自身の有効期間で失敗し得ます。何かを更新する前に、どれが失敗したのかを読んでください。

深さは、失敗した証明書を名指しする

OpenSSL の診断では、深さ 0 が対象の証明書、深さ 1 がそれに署名した発行者で、より大きい番号は信頼のアンカーへと続きます。深さ 1 で報告された期限切れは、リーフの現在の notAfter と矛盾しないため、目に見える証明書を再確認しても決してエラーを説明できません。

失敗した証明書の指紋を subject とともに記録してください。異なる証明書が同じ CA 名を持つことがあるからです。クロス署名はまさにその状況を生みます。同じ機関が複数回、異なる有効期間で現れ、検証者はあなたが予想しなかった方を選んだのです。なじみのあるラベルは識別子ではなく、指紋こそが同じ名前を共有する二つのオブジェクトを区別します。

証明書の役割が複数ある製品にも注意してください。OpenVPN Access Server では、ウェブインターフェースを保護する証明書は VPN 接続に使うものとは別であり、管理画面を開くブラウザーはトンネルの経路について何も証明しません。

信頼の入力はチェーンの候補とは同じではない

検証者に二つの入力を別々に、明示的に渡してください。信頼ファイルはあなたが受け入れるアンカーを保持し、信頼されないバンドルは経路を構築するために提供される中間証明書を保持します。両者を混ぜると、人は誤って中間証明書をルートに昇格させ、その後なぜ同じエラーがマシン間でついてくるのか不思議に思うのです。

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

既定の経路とストアを -no-CApath -no-CAstore で無効にすると、テストは正直なままです。結果はあなたが指定したファイルに依存し、ワークステーションがたまたま信頼するものには依存しません。OpenSSL の検証リファレンスはこれらのオプションと、それらが生成する診断を文書化しています。

-show_chain は検証が成功したときに構築されたチェーンを出力し、経路が意図したものかを確認するのに役立ちます。失敗したときは、報告された深さと subject を保持してください。その二つのフィールドが、次に読む人へどの証明書を調べるべきかを伝えます。

これがしないのは、各クライアントのポリシーを再現することです。ピン、目的の制限、クライアント固有の身元確認はクライアントの中にあり、このコマンドにはありません。サーバーで検証が通り、接続がまだ失敗するときに調べるべき設定はそれらです。二つの診断を分けておかないと、ピン留めエラーを追いながら健全な証明書を更新してしまいます。

この検査が証明することと、取りこぼすこと

これは、あなたが用意した信頼ファイルに対する経路と目的の検査です。HTTPS の名前検査には、適切なオプションで期待するホスト名を追加してください。VPN 接続では、クライアントに設定された身元確認を保ち、そのクライアントが実際に読む信頼素材を使ってください。

サーバーが送るのは候補の集合であり、あなたのクライアントが最終的に構築する経路ではありません。ローカルの信頼とライブラリの構築規則の両方が結果を形づくるため、同じ応答が一方のマシンでは検証でき、他方では失敗することがあります。同一の評価を前提にする前に、失敗するクライアントの維持された信頼ストアと TLS 実装を、動作するクライアントのものと比較してください。そこに差があれば、「このノートパソコンだけ失敗する」という報告の多くを説明できます。

各証明書の期間を一つずつではなく集合として見るには、次のように出力します。

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

二つ目のコマンドは、各ファイルを手作業でデコードせずに subject と発行者を一覧にします。こうして、リーフはまだ健全に見えるのに日付が過ぎた中間証明書を見つけられます。

検証を弱めずに経路を修復する

期限切れの中間証明書や古いクロス署名証明書が提供されている場合は、発行者が現在サポートするチェーンを入手し、サービスの文書化された証明書ワークフローで配備してください。クライアントに意図した維持されたアンカーがない場合は、管理された信頼設定かクライアントソフトウェアを更新します。メッセージを黙らせるためだけに、バンドル内のすべての証明書をルートとして印付ける近道には抵抗してください。

ルートの扱いには注記が必要です。要約はしばしばそれを誇張します。RFC 5280 はアンカーを予定経路の外にある入力として扱い、OpenSSL は自身のルート CA 証明書を含む有効性検査を文書化しています。どちらの記述もそれぞれのシステムでは正しく、あるライブラリのルート期限切れの挙動をすべてのクライアントに一般化すると、自信に満ちた誤答を生みます。

変更後は、影響を受けたクライアントで新しい認証を強制し、その具体的な期限切れメッセージが消えたことを確認してください。リーフ自体が不適切な場合にのみリーフを更新します。時刻検査を無効にしたり、過去のクロス証明書を復元したりしても、有効な現在の経路は作れません。次の失敗を先送りするだけです。