証明書のライフサイクルと失効

すべてのデジタル証明書には、作成から廃止まで定められたライフサイクルがあります。その段階は、申請と登録（鍵ペアを生成し、CSRを作成）、発行（CAが検証して署名）、導入（サーバーまたはデバイスにインストール）、使用（運用期間）、更新（有効期限前）、失効または期限切れ（ライフサイクルの終了）です。特に数千件の証明書を扱う企業など、大規模な環境でこのライフサイクルを管理するには、自動化と証明書ライフサイクル管理（CLM）ツールが必要です。手作業での追跡では、必然的に有効期限切れの証明書が発生し、障害につながるためです。

証明書のライフサイクルはCertificate Signing Request（CSR）から始まります。申請者は鍵ペアを生成し、公開鍵、Subject情報（CN、O、C）を含み、秘密鍵で署名したCSRを作成します。これにより、秘密鍵そのものを明らかにすることなく、秘密鍵を所有していることを証明できます。CSRはCAに提出され、CAが申請者の身元を検証し、承認した場合に証明書へ署名します。秘密鍵が申請者の管理下から離れることはありません。CSRの生成は鍵の強度が決まる重要な段階です。RSAでは最低2048ビット、ECCでは256ビットを使用します。

証明書は、notAfterの日付を過ぎる前に更新する必要があります。ベストプラクティスでは、有効期限の少なくとも30日前（多くの組織では60～90日前）に更新を開始します。更新では通常、新しいCSRと秘密鍵を生成してCAに提出し、証明書を導入しているすべてのサーバーで古い証明書と鍵を置き換えます。Let's EncryptはACMEプロトコルを使用してこの処理を自動化します。certbotツールは、証明書の残りの有効期間が30日未満になると自動的に更新します。証明書の期限が切れるとブラウザーエラーが発生し、ユーザーはサービスにアクセスできなくなります。

証明書の失効とは、予定された有効期限より前に証明書を無効にする処理です。失効の理由には、秘密鍵が侵害された（最も緊急性が高く、直ちに失効させる必要があります）、証明書が誤って発行された（ドメインや組織が間違っている）、Subjectの情報が変更された（会社名の変更、従業員の退職）、CA自体が侵害された場合などがあります。ブラウザーやシステムが証明書の失効を認識していなければ、その証明書への信頼を継続するため、盗まれた秘密鍵を持つ攻撃者が、証明書の期限が切れるか失効が認識されるまでMITM攻撃を実行できてしまいます。

Certificate Revocation List（CRL）は、CAが公開する署名付きリストです。まだ有効期限が切れていない、失効済み証明書のシリアル番号がすべて記載されています。クライアントはCRLをダウンロードしてキャッシュし、提示された証明書のシリアル番号がリストに含まれているかを確認します。CRLには大きな制約があります。サイズが非常に大きくなる可能性があり（大規模なCAでは失効済み証明書が数百万件に及びます）、クライアントが数時間から数日間キャッシュすることで反映に遅れが生じることがあり、接続のたびにCRL全体をダウンロードするのは非効率です。CRLは現在も使用されていますが、OCSPによって補完または置換されるケースが増えています。

OCSP（Online Certificate Status Protocol）は、クライアントがCRL全体をダウンロードせずに、証明書の失効をリアルタイムで確認できるようにします。クライアントは証明書のシリアル番号を添えて、CAのOCSPレスポンダーに問い合わせを送信します。レスポンダーは、証明書がgood（有効）、revoked（失効済み、失効日時と理由を含む）、またはunknown（不明）のいずれかを示す署名付き応答を返します。OCSPはCRLより高速で最新の情報を得られますが、TLS接続ごとにOCSPレスポンダーへの追加のHTTP往復が必要となり、遅延が発生します。OCSP応答にはCAが署名するため、改ざんを防止できます。

OCSP Staplingは、リアルタイムOCSPチェックに伴う遅延の問題を解決します。TLSハンドシェイクのたびにクライアントがCAのOCSPレスポンダーへ問い合わせる代わりに、サーバーがCAから自身のOCSPレスポンスを事前に取得し、それをTLSハンドシェイクに「ステープル」（添付）します。クライアントは、追加のラウンドトリップなしで、CAが署名した新しいOCSPレスポンスをサーバーから直接受け取ります。サーバーは通常、1時間ごとにステープル済みのOCSPレスポンスを更新します。OCSP Staplingは、失効チェックを維持しながら接続速度を向上させ、CAのOCSPレスポンダーの負荷を軽減します。

OCSP Must-Stapleは、サーバーがステープル済みのOCSPレスポンスを必ず提供するようブラウザーに指示するX.509拡張機能です。これがない場合、OCSPチェックに失敗するとブラウザーは「ソフトフェイル」を実行します。つまり、OCSPレスポンダーの障害によってすべてのTLS接続がブロックされるのを防ぐため、接続をそのまま許可します。攻撃者は、クライアントのOCSPリクエストを遮断してソフトフェイルの動作を悪用し、証明書が失効した後も有効であるかのように見せかけることができます。OCSP Must-Stapleは、有効なステープル済みレスポンスを必須にすることでこれを防ぎます。レスポンスがなければ、ブラウザーは接続を拒否します。導入の複雑さから、普及は依然として限定的です。

証明書の失効と証明書のピンニングは、どちらも不正な証明書を信頼してしまう問題に対処しますが、その方法は異なります。失効（CRL/OCSP）は事後対応型の仕組みです。問題が発見された後、CAが証明書を無効にします。ピンニングは事前対応型の仕組みです。アプリケーションが、あらかじめ承認された証明書以外を拒否します。CAが速やかに失効させられない場合でも機能するため、ピンニングは失効より強力な保証を提供しますが、導入や運用の柔軟性が低下します。Security+試験では、両方の仕組みを理解し、失効が標準的なPKIメカニズムである一方、ピンニングは追加的な防御策として任意に導入する仕組みであることを把握してください。

証明書が失効すると、CAは失効理由コードを設定します。これにより、クライアントや管理者は失効の理由を把握しやすくなります。RFC 5280で定義されている一般的な理由コードには、keyCompromise（秘密鍵が漏えいした）、cACompromise（発行CAが侵害された）、affiliationChanged（主体の所属組織が変更された）、superseded（置き換え用の新しい証明書が発行された）、cessationOfOperation（ドメインが使用されなくなった）、privilegeWithdrawn（権限が取り消された）があります。理由コードはCRLエントリとOCSPレスポンスの両方に含まれ、失効イベントを調査するインシデント対応チームに状況を伝えます。

Let's Encryptで使用されているACME（Automatic Certificate Management Environment）プロトコルは、証明書のライフサイクル全体を自動化します。ACMEクライアント（certbotなど）は、人手を介さずに証明書の要求、更新、デプロイを自動的に行います。CAはドメイン検証チャレンジを使用してドメインの所有権を確認します。HTTP-01チャレンジでは、既知のURLに特定のファイルを配置します。DNS-01チャレンジでは、DNS TXTレコードを作成します。ACMEは証明書管理を大きく変革しました。現在では、Let's Encryptの90日間有効な証明書がインターネット上のHTTPS通信の大部分を支えており、それらはすべて自動的に更新されています。

このレッスンで扱ったCompTIA Security+（SY0-701）の概念について、理解度を確認しましょう。

このレッスンでは、証明書のライフサイクルがCSRの生成から発行、デプロイ、そして更新または失効まで続くこと、CRLが失効証明書の一覧をまとめて提供するのに対してOCSPは証明書ごとのステータスをリアルタイムで提供すること、OCSP StaplingがリアルタイムOCSPの遅延を解消すること、そしてACME（Let's Encrypt）が更新を含む証明書のライフサイクル全体を自動化することを学びました。次はPKIのユースケースについて学びます。