中間CA証明書の失効に緊急対処した話
リセラーを通じて、クイック認証SSLの発行元認証局（GMOグローバルサイン社）より、中間CA証明書の失効に関する【重要メール】が来ていたとのこと。
中間証明書を期限前に失効させる理由はセキュリティリスクの存在が確認されたため。このようなインシデントはたまにあることで、サーバ証明書の最長有効期限が１年に短縮されたのも、影響を受けるサーバを少しでも減らす狙いがある（タイミング良く更新されていれば再発行が不要なため）。Let's Encrypt の自動更新が90日と短いのも同じ理由である。
中間証明書が失効されると、その配下のサーバ証明書も無効になり、ブラウザで「この証明書は信頼できない」という旨の警告が表示される。
ChromiumベースのブラウザではNET::ERR_CERT_REVOKEDの表示になる
いずれにせよ、失効日は2021年1月20日とのことで、至急の対応をお取引先様から要請された。
（こちらとしても、公にも発表されている重大インシデントを見落としていたのは迂闊だった）
再発行手順
再発行すると、失効対象の中間証明書ではなく、新しい中間証明書からサーバ証明書が発行される。
秘密鍵の入れ替えが不要な場合、前回と同じCSRで再発行してくれるようなので、速攻で手続きを進めた。
手続きから30分ほどで、サーバ証明書と中間証明書がメールで送られてきた。公開鍵なので厳重に扱う必要は無い。
インストール手順
サーバ証明書と中間証明書を結合し、Apache2.4.8 のSSLCertificateFileディレクティブで指定されたパス名でアップロードする。従前のSSLCertificateChainFileは deprecated になっている。
Apacheを再起動し、中間証明書が新しくなったことをブラウザから確認しよう。
確認手順
ブラウザで鍵マークをクリックすると、サイトが所有する証明書の内容を見ることができる。
【証明のパス】をクリックすると、サーバ証明書の上に、ルート証明書と１つ以上の中間証明書が階層表示されているはずだ。これを証明書チェーンという。
中間証明書を選択し、【証明書の表示】をクリックする。
有効期間が以前と変わっていればOKだ。
CRLとOCSP
証明書が失効していると、ブラウザはサイトを閲覧させないように機能する。
では、どのように失効を判断しているのだろうか？
それは、証明書失効リスト（CRL） の中に、サーバが提示した証明書のシリアル番号が登録されていれば失効と判断している。CRLは認証局のサーバに保管されていて、そのURLは証明書に記載されている。確認してみよう。
【詳細】の「CRL配布ポイント」を選択すると、URLが確認できる。アクセスしてみよう。
ダウンロードして開くと、以前の中間証明書のシリアル番号が、失効した証明書として登録されており、その失効日が2021年1月20日になっているのを確認できた。
CRLを見ると分かる通り、過去にその認証局で発行された有効期間内の証明書のうち、期間途中で失効した証明書のシリアル番号がすべて記載されているため、CRLのファイルサイズが巨大化している。パフォーマンスの悪影響が問題になったので、これを解決するために生まれたのがOCSPというプロトコル。CRLではリストをダウンロードしてから検証する必要があったが、OCSPでは、シリアル番号を送信すると、認証局のサーバ（OCSPレスポンダ）が失効の有無をリアルタイムで回答するのでクライアントの処理も軽い。
OCSPレスポンダのURLは、証明書の「機関情報アクセス（Authority Infomation Access）」に記載されているので、openssl ocspコマンドで失効の有無を確認できる。
教訓
過去にルート証明書や中間証明書の秘密鍵が認証局などから漏洩し、チェーンしている全ての証明書を失効させる騒ぎもあったようだ。
また、グローバルサインのルート証明書が一時的に失効するという障害もあった。
サイト管理者には、認証局の障害情報もチェックすることが求められる。
Discussion