_ 先週 GlobalSign がやらかした障害について 詳細な報告書が出てた。一読してだいたい理解できたけど、字ばっかで図がないのでやっぱりわかりづらい。わかりやすくしてみる。
_ 障害発生前の状態。
+----------+ +--------+ +----------+
| Root(R1) |-----| 中間CA |------| EE証明書 |
+----------+ +--------+ +----------+
|
+----------+ +---------+
| Root(R2) |-----|crossroot|
+----------+ +---------+
_ で、このクロスルート CA が引退することになったので、10/7 にこいつの証明書を失効させて CRL に載せたそうな。CRL を使って失効検証している場合、この時点で R2 による検証はできなくなり、R1 に一本化された。ここまでは問題なし。
_ OCSP での失効処理は少し遅れて 10/13 に実施。が、ここに不具合があり、クロスルート証明書を失効させるつもりが、同じ subject で同じ鍵である Root(R1) の証明書の方を失効扱いにしてしまったらしい。ただ、この R1 は CRL も OCSP もどちらも配布ポイントが証明書に定義されていなかったので、実際には失効させようにもできない。なので、次善策として、R1 が発行したすべての証明書を失効させるという動作になり、結果として R1 の下にいるすべての中間 CA の証明書が失効した、と。やらかしたことに気がついて OCSP レスポンダはほどなく修正したんだけど、これはブラウザや OS によってキャッシュされるので、影響は数日続く(逆に言えば、障害以前のキャッシュがあれば障害の影響を受けなかった)。
_ ここから globalsign の報告書には記載されていないこと。
_ 証明書の失効状態は大きくわけて2つある。revoked(失効)と hold(一時停止)。通常失効といえば前者で、失効させたら二度と復活できない。一方、秘密鍵がどっかいっちゃった、いま探してるけど第三者に盗まれる恐れはないよ、なんてときには一時的に hold という状態にすることができる。で、hold な状態から有効な状態に戻すことはできるけど、そうではない revoked な状態から有効な状態に戻すことはできない。globalsign は間違えて失効させてしまった、と言ってるわけで、キャッシュ切れを待とうが何をしようが一度失効させてしまったものを復活させることはできないのでは？ やろうと思えば CRL から消して OCSP の応答を good に変えることでできなくはないけど、それをやったことが発覚すると CA の認定取り消しもありうるレベルの運用規程違反じゃないの？
_ …と思っていた。調べてみたら、RFC6960 (OCSP) にこう書かれていた。
The "revoked" state indicates that the certificate has been revoked, either temporarily (the revocation reason is certificateHold) or permanently.なんと、OCSP では失効と一時停止の区別がなかった。区別がないので、いったん失効扱いにした証明書が後から復活しても OCSP ならとくに問題ないらしい(CRL ならアウト)。
_ もひとつ。OCSP のキャッシュ切れが待てない場合の対処として、別に作成した中間証明書を使ってくれ、と 案内していた。が、R1 が発行した中間 CA は OCSP からは復活したので、もともとの証明書と緊急対応用の証明書で、同じ中間 CA の証明書が同時に2枚存在することになってしまう。そういうのってアリなの？ 片方を失効させなくていいの？
_ …と思って確認してみたら、緊急対応用の中間証明書は R1 でも R2 でもない別のルート CA である R3 から発行されていた。
+----------+ +---------+ +----------+
| Root(R1) |-----| 中間CA1 |------| EE証明書 |
+----------+ +---------+ +----------+
|
+----------+ +---------+ |
| Root(R3) |-----| 中間CA3 |---------+
+----------+ +---------+