ca md too weak：証明書を再発行するか、レベルを下げるか

OpenVPN のクライアントが、先月は動いていたのに今は起動時に ca md too weak で失敗する。ディスク上のプロファイルは動いていたものとバイト単位で同じだ。このメッセージが指すのは認証局の証明書に付いた署名であり、データ暗号や auth ダイジェストやアカウントのパスワードではない。修正が新しい識別情報なのか、新しいチェーンなのか、意図的なポリシー変更なのかは三つの条件で決まる。順に追えば、ホスト上のすべての TLS 接続を弱めてトンネルを戻すというよくある結末を避けられる。

エラーが実際に示しているもの

OpenSSL はチェーンを組み立てる最中にこの検証エラーを出す。CA として働く証明書が、ライブラリのセキュリティレベルがもう受け付けない署名ダイジェストを抱えている場合だ。MD5 は既定のレベルで拒否され、SHA-1 はレベルを上げると拒否される。ここでは末端の証明書のダイジェストよりも、それに署名する発行者のダイジェストのほうが重い。同じポリシーは、発行された当日にはごく普通だったルートも拒否しうる。

だから auth や data-ciphers を編集してもこの失敗には効かない。これらの設定はハンドシェイク後にパケットをどう守るかを決めるが、拒否された対象はトンネルが存在する前に調べられる身元証明書だ。証明書は有効期間の内側にゆったり収まっていても、ライブラリが受け付けない署名を帯びていることがある。

検査を頭の中で分けておけば、エラーは謎ではなくなる。有効期限、鍵の用途、署名ダイジェストは独立した試験であり、そのうちのちょうど一つが今失敗したのだ。

条件その一――拒否された対象はルートか

プロファイル内の各証明書を出力し、subject と issuer を読む。自己署名のルートは両方に同じ値が現れ、その署名アルゴリズムがチェーン全体の土台になる。弱いダイジェストがそこにあると、下の末端はすべて問題を受け継ぐ。後で機械的に比べられるよう、アルゴリズムを subject の隣に書き留めておく。

まとめた CA ファイルは複数のブロックを含むことが多いので、最初のものが犯人だと決めつけず、実際に読み込まれるブロックを特定する。コマンド openssl x509 -in ca.pem -noout -subject -issuer -text は一度に一つの証明書しか記述しないため、複数入っているなら先に束を分割する。出力された署名アルゴリズムを、ルートが作られた時代に想定されるダイジェストと比べる。

弱いルートの下で SHA-256 で署名された末端も失敗する。チェーンの検査は上まで辿るからだ。この順序があるからこそ、次の条件が効いてくる。

条件その二――発行者を管理しているか

ルートが自組織のものなら、恒久策は現代的なダイジェストを持つ新しいルートと再発行した末端であり、一回のプロファイル更新として配る。そのためには保守時間帯と、同じ日に更新を受けられない機器のための計画が要る。

チェーンを第三者が発行したなら、策はその運用者への依頼であり、手元で有効な唯一の行動は古い材料への依存をやめることだ。PEM のテキストを編集しても、ファイルを保存し直しても、署名が覆う範囲は何も変わらない。

中間の事例には名前を与えておきたい。現在の既定より古いが、他のシステムが信頼する材料に今も署名している内部ルートだ。これを差し替えるには、古い証明書を指紋で固定している機器を含め、すべての利用者を棚卸しする必要がある。変更を予定する前にその利用者を数えること。一台を取りこぼすルート交換は、起動時のエラーを停止と引き換えにする。

条件その三――レベルを下げると他に何を受け入れるか

セキュリティレベルを下げる、あるいは OpenVPN の旧証明書プロファイルを選ぶと、クライアントは再び古いダイジェストを受け入れる。同時に同じライブラリの他の検査も緩み、そのプロセスが張るすべての接続に及ぶ。

実験室や、代替材料を用意する間の短い橋としては正当化できる。ただし例外は一つのプロファイルに限定し、終了日を持たせること。共用ホストの恒久設定にすると、そこにあるすべての TLS クライアントが何を信頼するかを静かに広げてしまう。

例外は所有者と撤去手順とともに書き残す。文書化されていないレベルの変更は半年後には誤りと区別がつかず、次の技術者はそれが判断だったことを知らない。

判断を規則として書く

発行者を管理し、その利用者を数え上げられるならチェーンを差し替える。できないなら発行者へエスカレーションする。レベルを下げるのは、交換がすでに予定されている、日付入りで限定的な例外としてのみ。それ以外は同じ証明書を置き去りにし、リスクをより見えにくい場所へ移すだけだ。

そのうえで清潔なクライアントからプロファイルを再試験し、ハンドシェイクが完了することを確かめ、それでも失敗するなら拒否の文言を正確に残す。正確なエラーメッセージは、次の層を持つ者に渡せる最も安いものだ。