証明書の失効確認が失敗する：どのホストが何に到達できないのか

証明書が有効期間内にあっても VPN は依然として 認証失敗を報告する ことがあり、誰かが証明書が失効したと結論づける。これは三つの別個の事実である。失効データは、検証を行うデバイス自身が、証明書の中に示された公開ポイントから取得しなければならない。そのデバイスがポイントに到達できないとき、確認は証明書の状態とは無関係な理由で失敗する。

取得経路は検証者のもの

まず検証者を特定する。ノート PC がゲートウェイの証明書を確認する場合、取得を行うのはノート PC である。ゲートウェイがクライアント証明書を確認する場合、取得を行うのはゲートウェイである。バックエンドの認証サービスが、独自のネットワーク位置を持つ第三の検証者として加わることがある。それぞれインターネットへの経路もプロキシ設定も異なる。管理者のワークステーションで集めた証拠は、DMZ 内のサーバーについて何も語らない。

何かを変更する前に、証明書、検証者、試行時刻、正確なステータスコードを記録しておく。

証明書から公開ポイントを読む

証明書は自身の状態がどこにあるかを示している。CA のアドレスを推測するのではなく、そのフィールドを読む。

openssl x509 -in gateway.cer -noout -text | grep -A3 "CRL Distribution Points"
openssl x509 -in gateway.cer -noout -text | grep -A2 "Authority Information Access"

最初の拡張は CRL 配布ポイントを列挙し、二つ目は機関情報アクセスの方式を列挙する。後者には OCSP の状態や発行者の証明書の取得が含まれ得る。これらは別の仕組みであり、OCSP レスポンダーは CRL ファイルではない。公開ホストは CA のマシンではなく普通の Web サーバーであることが多い。オフラインの発行者が署名した CRL を別のサーバーが配布できるからだ。したがって CA へのアクセスと表現されたファイアウォール規則は、実装もレビューもできないほど曖昧である。

検証するデバイスから取得を試す

実際に検証を行う環境で、承認済みの証明書素材と秘密鍵なしで取得テストを実行する。

certutil -urlfetch -verify .\client-test.cer
curl -sS -o /dev/null -w "%{http_code}\n" http://crl.example.com/ca.crl

certutil の実行はチェーンを検証し、どの URL の取得が成功または失敗したかを報告する。一方 curl の呼び出しは、同じホストから一つの公開アドレスだけを試し、ステータスコードのみを返す。到達可能なアドレスからの取得失敗は内容や署名の問題を示し、接続エラーはルーティング、DNS、プロキシの問題を示す。両方の結果を残すこと。取得が一つ成功しても、チェーン全体が使えることにはならない。例のホストとパスは、証明書で見つかった配布ポイントに置き換える。

欠落データと失効状態を切り分ける

外から見ると四つの結果は似ている。ポイントに到達できない、リストが古い、リストが誤った発行者によって署名されている、証明書が本当に失効している、の四つである。状態の結果と言えるのは最後の一つだけで、アクセスを外す正当化になるのもそれだけである。キャッシュは事態をさらに複雑にする。以前に取得したデータが、次回の更新まで壊れた公開経路を隠してしまうからだ。失効確認を無効にする、無関係な証明書を削除する、ゲートウェイを再起動する、いずれも診断を作業で置き換えているだけである。

修正後は新しい認証を強制し、意図した状態取得が成功することを確認する。管理されたテスト用の識別情報がある場合は、それが依然として拒否されることを確認する。確認を外して得た可用性は修復ではないからだ。