図1　A社のアプライアンスPKIサーバーを修理して新しい証明書を発行したところ，相互認証ができなくなってしまった
CA局の秘密鍵が新しく作り換わったため，新規特約店Yのクライアント証明書は，信頼できるCA局が発行した証明書とみなされない。

ファイル・システムに障害発生

　相互認証の手順はこうだ。(1)特約店のパソコンが，SSLの接続要求をSSLアクセラレータへ送信，(2)SSLアクセラレータは，パソコンに対してサーバー証明書を送信するとともに，クライアント証明書の送信を要求，(3)特約店のパソコンは，クライアント証明書をSSLアクセラレータへ送信，(4)証明書を使って相互に認証した後に，暗号鍵を生成，暗号データを相互にやり取りする。

　ところが，ある日突然，電源ユニットが壊れ，稼働中のPKIサーバーが正常に動作しなくなってしまった。しかも電源が突然落ちたことによって，PKIサーバーのコンパクト・フラッシュ（フラッシュ・メモリーを用いた外部記憶装置）上に作っていたファイル・システムが壊れてしまった。ファイル・システムをバックアップしていなかったため，元の状態に戻せない。

　仕方がないので，PKIサーバーのベンダーとの保守契約に基づいて，サーバー・マシンを修理した。修理されて戻ってきたPKIサーバーに，管理ツールを使って壊れる前のPKIサーバーと全く同じ設定を施した。

　PKIサーバーの修理直後，新たな特約店が1店舗加わった。そこで，PKIサーバーでクライアント証明書を発行して新規特約店のパソコンにインストールした。ところが，新規特約店のパソコンからWebサーバーへ接続しようとすると認証が通らず，接続ができない状態になった（図1[拡大表示]）。

　調べてみると，接続できない原因は単純だった。PKIサーバーを修理した際に，全く新しいCA局の秘密鍵を生成していたのだ。以前と同じ設定なのに同じ秘密鍵が作れないのは，疑似乱数を使って秘密鍵を生成するからである。