公開鍵証明書は、秘密鍵の流出など不測の事態には有効期限内でも失効させることができます。このため、証明書の受け取り側は受け取った証明書の有効性について確認する必要があります。証明書の有効性情報の入手は当初CRL(Certificate Revocation List)やOCSP(Online Certificate Status Protocol)のようにTLSハンドシェークのスコープの外で実現されていました。OCSP Stapling ではハンドシェークの一部としてTLS拡張に取り込まれ、TLS1.3でそれらが整理され現在に至っています。
短い間にいろいろな方法が登場したので少しわかりにくくなっているので、この記事ではその経緯を含めてまとめてみます。
なお現在では、証明書ステータスの確認方法としてはOCSP Stapling v2以降の使用が推奨されます。また、TLSの基本的なピア認証プロトコルはクライアント、サーバでほぼ対称となっているのですが、TLS1.2まではOCSPはサーバ認証のみで、クライアント認証におけるOCSPはTLS1.3で初めてサポートされました。
1) CRL
初期の証明書有効性の管理メカニズムとしては、失効した証明書の一覧は証明書失効リスト(CRL) のフォーマットが標準化されました。クライアントはCRLを定期的に入手しておくことで、受け取った証明書の有効性を確認することができます。しかし、クライアント自身がCRL内の証明書情報を確認しなければならず、ネットワークの規模が大きくなりリストのサイズが大きくなるとクライアントにとって負担となってしまいます。
2) OCSP
クライアントのそのような負担を軽減するために、受け取った証明書だけに絞ってその有効性をOCSPレスポンダーに問い合わせるプロトコルとしてOCSP(RFC6960)が開発されました。OCSPの場合、クライアントはOCSPレスポンダーに対して有効性を確認したい証明書のシリアルナンバーを送り、レスポンダーは問い合わせを受けた証明書についての確認結果を返却するのでクライアントの処理負荷が軽減されます。
しかし、このネットワーク構成ではレスポンダー側にトラフィックが過剰に集中してしまう点が大きな課題となってしまいました。また、レスポンダーがどのような形で失効情報を得るかについては規定されていないので、レスポンダーが参照する失効情報自身のリアルタイム性が保証されているわけではありませんでした。
3) OCSP Stapling
このように初期のOCSPでは証明書のステータス情報の入手にはTLSとは独立したプロトコルが規定されていました。しかし、その後開発されたOCSP Staplingでは、クライアントはOCSPレスポンダーではなくサーバに対してTLSハンドシェークの一環として証明書の有効性確認要求のプロトコルが標準化されました。これによってクライアントはサーバからの確認結果だけで証明書の有効性を判定できるようになりました。
具体的には、クライアントからの要求にはRFC6066でTLS拡張の一つとして追加された証明書ステータス要求(Certificate Status Request)を使用します。これに伴ってサーバからの応答としてハンドシェークレコードにCertificateStatusが追加されました。サーバはCertificateStatusレコードにOCSP Responseをのせることによって証明書ステータスを返却します。
4) OCSP Stapling Version 2
通常、CAは階層構造を構成していて、それに対応した複数の証明書がチェーンされます。有効性確認は中間CAを含めた証明書についても行う必要がありますが、TLS1.2では一つのClientHelloには一つの証明書ステータス要求拡張しか設けられないという制限があり、中間CA証明書のステータスを含めて要求することができませんでした。
これを解決するためOCSP Stapling バージョン2 として、RFC6961(Multiple Certificate Status Request Extension)で規定が修正拡張されました。バージョン2ではサーバは直接CAに対して有効性確認時のタイムスタンプもクライアントに応答します(RFC6962: Signed Certificate Timestamp)。これによって、クライアントはレスポンスの鮮度を含めて証明書の有効性を確認することができるようになりました。サーバ側も鮮度が許す限りCAへの有効性確認要求を束ねることができるので、問い合わせに対応するCAの負荷を大幅に削減することができるようになりました。
5) TLS1.3のOCSP Stapling
TLS1.3では、複数OCSPレスポンダーの証明書ステータスが存在できるようになりこの障害がなくなりました。このためTLS1.3ではクライアントからのステータス確認要求においてはRFC6961の規定する複数証明書ステータス拡張は廃止され、当初のRFC6066の証明書ステータス要求のほうが採用されています。サーバからのレスポンスもCertificate Entry拡張内に対応する証明書とともにRFC6066に準拠したOCSP Responseが設けられました。
TLS1.3ではリクエストとレスポンスのためのTLS拡張が整理されたことにより、サーバからクライアントに対しても同様の証明書ステータス要求を出すこともできるようになりました。この場合、サーバはCertificateRequestにstatus_requesを乗せて要求を出します(RFC8446 Section 4.4.2.1)。
この記事の内容を含めてTLプログラミングについて解説をまとめる機会をいただきました。興味のあるかたはご覧ください。徹底解剖 TLS 1.3 (翔泳社から 3/7刊行)。