• Javaソフトウェア
• Java SEダウンロード
• Java SE 8ドキュメント

Search

次の項目について説明します。

• Introduction
• クライアント主導のOCSPと証明書失効
  • クライアント主導型OCSPを使用するTLSハンドシェーク
  • クライアント主導のOCSPを使用するためのJavaクライアントの設定
• OCSPプルと証明書失効
  • OCSPステープリングを使用するTLSハンドシェーク
  • ステータス要求と複数ステータス要求との比較
  • OCSPの要求と応答
  • OCSPステープリングを使用するためのJavaクライアントの設定
  • OCSPステイプルを使用するようにJavaサーバーを設定
• OCSPプル構成のプロパティ
  • サーバー側プロパティ
  • クライアント側の設定
• PKIのOCSPサポート
  • 最大許容クロック・スキュー

Introduction

JDK 8u261以降で使用可能なオンライン証明書ステータス・プロトコル(OCSP)を使用して、Transport Layer Security (TLS)ハンドシェイク中のX.509証明書失効ステータスを確認します。

TLSで使用されるX.509 証明書は、証明書が破損したと考えられる理由がある場合は、発行認証機関(CA)によって取り消すことができます。 次のいずれかの方法を使用して、TLSハンドシェイク中に証明書の失効ステータスを確認できます。

• 証明書失効リスト (CRL): CRLは、失効した証明書の単純なリストです。 証明書を受け取るアプリケーションは、CRLサーバーからCRLを取得し、受け取った証明書がリストにあるかどうかを確認します。 CRLの使用には、証明書を失効できるという意味で、不便な点が2つあります。

  • CRLは非常に大きくなる可能性があるため、ネットワーク・トラフィックがかなり増加する可能性があります。

  • 多くのCRLは長い有効期間で作成されます。これにより、証明書がその有効期間内に失効し次のCRL更新までリストに含まれなくなる可能性が高くなります。

  「Java PKIプログラマーズ・ガイド」の 「証明書/CRLストレージ・クラス」を参照してください。

• クライアント駆動型OCSP: クライアント駆動型OCSPでは、クライアントはOCSPを使用してOCSPレスポンダに連絡し、証明書の失効ステータスを確認します。 必要なデータ量はCRLの場合よりも通常は少なく、OCSPレスポンダは、CRLよりも最新の失効ステータスを把握している可能性があります。 サーバーに接続する各クライアントは、検査される各証明書に対してOCSPレスポンスを必要とします。 サーバーが一般的なサーバーであり、多くのクライアントがクライアント駆動型OCSPを使用している場合、これらのOCSPリクエストはOCSPレスポンダのパフォーマンスに悪影響を及ぼす可能性があります。

• OCSPステープリング: OCSPステープリングにより、サーバーはクライアントではなく、OCSPレスポンダにリクエストを行うことができます。 サーバーは証明書に対するOCSPレスポンスをプルし、TLSハンドシェイク中にクライアントに返します。 このアプローチでは、発行CAではなく、証明書のプレゼンタがOCSPレスポンスを提供するためのリソース・コストを負うことができます。 また、サーバーはOCSPレスポンスをキャッシュしてすべてのクライアントに提供することもできます。 これにより、OCSPレスポンダの負荷が大幅に軽減されます。レスポンスはキャッシュされ、各クライアントではなくサーバーによって定期的にリフレッシュされるためです。

クライアント主導のOCSPと証明書失効

クライアント駆動オンライン証明書ステータス・プロトコル(OCSP)を使用すると、クライアントは、Transport Layer Security (TLS)ハンドシェイク中にOCSPレスポンダに接続することで、証明書失効ステータスを確認できます。

クライアント主導のOCSPリクエストは、クライアントがサーバーから証明書を受信して検証した直後にTLSハンドシェイク中に発生します。

クライアント主導型OCSPを使用するTLSハンドシェーク

クライアント主導のOCSPは、クライアントとサーバー間のTLSハンドシェイク中に使用され、サーバー証明書失効ステータスを確認します。 クライアントは証明書を受け取った後、証明書検証を実行します。 検証が成功した場合、クライアントは、証明書が発行者によって取り消されていないことを検証します。 これは、OCSPレスポンダにOCSPリクエストを送信することによって行われます。 OCSP応答を受け取ると、クライアントは、TLSハンドシェークが完了する前にこの応答を確認します。

次の図は、クライアント駆動型OCSPがTLSハンドシェイクにどのように適合するかを示しています:

クライアント主導のOCSPによるTLSハンドシェイク

この図は、次の順序を示しています:

1. クライアントは、サーバーにClientHelloメッセージを送信します。

2. サーバーはこのメッセージを受信して処理します。

3. サーバーは、ServerHelloメッセージ、それに続く追加のServerHelloメッセージ、およびServerHello完了メッセージをクライアントに送信します。

4. クライアントはサーバー証明書を検証します。 クライアントは、この証明書のOCSPレスポンダにOCSPリクエストを送信します。

5. OCSPレスポンダはリクエストを受信し、OCSPレスポンスをクライアントに返します。

6. クライアントは、OCSPレスポンスをチェックして、証明書が取り消されたかどうかを判断します。

7. クライアントおよびサーバーは、TLSハンドシェイク(複数の追加メッセージが必要)を完了します。

通常、クライアントは証明書のAuthority Information Access (AIA)拡張子を調べることによってOCSPレスポンダURLを見つけますが、システム・プロパティを使用して静的URLに設定することもできます。

クライアント主導のOCSPを使用するためのJavaクライアントの設定

失効チェックを有効にしてOCSPを有効にすることで、クライアント主導のOCSPが有効になります。

クライアント主導のOCSPを使用するようにJavaクライアントを構成するには、TLSを使用してサーバーに接続するようにJavaクライアントを構成する必要があります。

1. 失効チェックを有効にします。 これを行うには、異なる2通りの方法があります。
   • システム・プロパティcom.sun.net.ssl.checkRevocationをtrueに設定します。
   • PKIXParametersでsetRevocationEnabledメソッドを使用します。
2. クライアント主導型OCSPを有効にします。

   セキュリティ・プロパティocsp.enableをtrueに設定します。

両方のステップが必要です。 ocsp.enable設定は、失効チェックが有効でないかぎり無効です。

OCSPプルと証明書失効

オンライン証明書ステータス・プロトコル(OCSP)ステープリングでは、発行元の証明書発行局(CA)ではなく、証明書の提示者が、証明書の失効ステータスを含むOCSP応答の提供のリソース・コストを負担できます。

OCSPステープリングを使用するTLSハンドシェーク

OCSPプルは、クライアントとサーバーの間のトランスポート層セキュリティの間に、サーバー証明書の失効状況を確認するために使用されます。 サーバーは、OCSPレスポンダにOCSPリクエストを行い、クライアントに返された証明書に対するOCSPレスポンスをプルします。 サーバーがOCSPレスポンダにリクエストを行うようにすることで、レスポンスをキャッシュしてから、多くのクライアントで複数回使用することができます。

TLSハンドシェークは、TLSのClientHelloメッセージで始まります。 OCSPステッピングを使用すると、このメッセージは、サーバーがOCSPリクエストを実行する必要があることを示すstatus_request拡張子を持つサーバーに送信されます。 ClientHelloメッセージの処理後、サーバーは証明書ごとにOCSPリクエストを適切なOCSPレスポンダに送信します。 サーバーはOCSPレスポンダからOCSPレスポンスを受信すると、そのstatus_request拡張子を持つServerHelloメッセージを送信し、OCSPレスポンスがTLSハンドシェイクで提供されることを示します。 サーバーはサーバー証明書チェーンを提示し、その後にそれらの証明書の1つ以上のOCSPレスポンスで構成されるメッセージが表示されます。 プルされたOCSPレスポンスで証明書を受け取ったクライアントは、各証明書を検証し、その後、ハンドシェイクを続行する前にOCSPレスポンスをチェックします。

クライアントの視点から述べると、証明書のための、サーバーからのステープリング済OCSP応答がない場合、次に当てはまると、クライアントはクライアント主導型OCSPまたは証明書失効リスト(CRL)を使用して失効情報を取得しようとします。

• RevocationEnabledフラグは、PKIXParameters.setRecovcationEnabledメソッドを介してtrueに設定されます。

• OCSPチェックを有効にするには、ocsp.enableセキュリティ・プロパティをtrueに設定します。

次の図は、クライアント駆動型OCSPがTLSハンドシェイクにどのように適合するかを示しています:

OCSPプルでのTLSハンドシェイク

この図は、次の順序を示しています:

1. クライアントは、ステータス・リクエスト拡張を含むClientHelloメッセージをサーバーに送信します。

2. サーバーはこのメッセージを受信して処理します。

3. サーバーは、この証明書のOCSPレスポンダにOCSPリクエストを送信します。

4. OCSPレスポンダはリクエストを受信し、OCSPレスポンスをサーバーに戻します。

5. サーバーは、ステータス・リクエスト拡張を含むServerHelloメッセージをクライアントに送信します。

6. サーバーは、クライアントに証明書メッセージを送信します。

7. サーバーは、クライアントに証明書ステータス・メッセージを送信します。

8. サーバーは、追加のServerHelloメッセージ、およびServerHello完了メッセージをクライアントに送信します。

9. クライアントはサーバー証明書を検証

10. クライアントは、証明書ステータス・メッセージでOCSPレスポンスをチェックして、証明書が取り消されたかどうかを判断します。

11. クライアントおよびサーバーは、TLSハンドシェイク(複数の追加メッセージが必要)を完了します。

OCSPチェックは、失効チェック中にCRLと連動して機能します。 「PKIのOCSPサポート」を参照してください。

ステータス要求と複数ステータス要求との比較

OCSPステープリング機能は、TLS Certificate Status Request拡張機能(RFC 6066の第8項)およびMultiple Certificate Status Request拡張機能(RFC 6961)を実装します。

TLS証明書ステータス・リクエスト拡張は、複数の証明書ステータス・リクエスト拡張が証明書チェーン内のすべての証明書の失効情報をリクエストする間に、証明書チェーン内のサーバー証明書のみの失効情報をリクエストします。 サーバー証明書の失効情報のみがクライアントに送信される場合、チェーン内の他の証明書を、証明書失効リスト(CRL)またはクライアント主導型OCSPを使用して検証できます(ただし、クライアントを、これを行うように設定する必要があります)。

TLSによって、サーバーがクライアントの証明書も要求するようにできますが、クライアントが適切なOCSPレスポンダに連絡して、サーバーに送信された証明書に応答をステープリングできるようにする、OCSPステープリングでの用意はできていません。

OCSPの要求と応答

OCSPリクエスト・メッセージとレスポンス・メッセージは通常、暗号化されていないHTTP経由で送信されます。 レスポンスはCAによって署名されます。

必要に応じて、ExtendedSSLSessionオブジェクトでgetStatusResponsesメソッドをコールすることで、プルされたレスポンスをクライアント・コードで取得できます。 メソッド・シグネチャは次のとおりです。

public List<byte[]> getStatusResponses();

OCSPレスポンスは、RFC 6960にあるASN.1で記述された形式の識別エンコーディング規則(DER)を使用してエンコードされます。

OCSPステープリングを使用するためのJavaクライアントの設定

オンライン証明書ステータス・プロトコル(OCSP)ステッピングは、システム・プロパティjdk.tls.client.enableStatusRequestExtensionをfalse (デフォルト値)に設定することで、クライアント側で有効にします。

サーバーから返された証明書にプルされたOCSPレスポンスを使用するようにJavaクライアントを構成するには、TLSを使用してサーバーに接続するようにJavaクライアントを設定しておく必要があります。また、サーバーはOCSPレスポンスをプルするように設定する必要があります。それがTLSハンドシェイクの一部を返す証明書。

1. クライアントでOCSPステープリングを有効にします。

   必要に応じて、システム・プロパティjdk.tls.client.enableStatusRequestExtensionをtrueに設定します。

2. 失効チェックを有効にします。 これを行うには、異なる2通りの方法があります。
   • システム・プロパティcom.sun.net.ssl.checkRevocationをtrueに設定します。 これは、コマンドラインまたはコードで行うことができます。
   • PKIXParametersクラスでsetRevocationEnabledメソッドを使用します。

   クライアントがサーバーから受信したプルされたレスポンスを証明書検証に含めるには、失効チェックをtrueに設定する必要があります。 失効チェックがtrueに設定されていない場合、失効情報の有無やステータスに関係なく、接続を続行できます

OCSPステイプルを使用するようにJavaサーバーを設定

オンライン証明書ステータス・プロトコル(OCSP)のステッピングは、システム・プロパティjdk.tls.server.enableStatusRequestExtensionをtrueに設定することでサーバー上で有効になります。 (デフォルトでは、falseに設定されています。)

次のステップを使用して、Javaサーバーを構成してOCSPレスポンダに接続し、OCSPレスポンスをクライアントに返す証明書にプルすることができます。 Javaサーバーは、TLSを使用するクライアントに応答するように既に設定されている必要があります。

1. サーバーでOCSPステープリングを有効にします。

   システム・プロパティjdk.tls.server.enableStatusRequestExtensionをtrueに設定します。

2. オプション: 必要に応じて他のプロパティを設定します。 有効なプロパティのリストは、次の項"OCSPステープリング構成プロパティ"を参照してください。

OCSPプル構成のプロパティ

このトピックでは、オンライン証明書ステータス・プロトコル(OCSP)を使用する場合のさまざまなプロパティの設定の影響について説明します。 これは、クライアント主導のOCSPとOCSPプルの両方で使用されるプロパティを示しています。

サーバー側プロパティ

ほとんどのプロパティは、SSLContextインスタンス化時に読み取られます。 つまり、プロパティを設定する場合は、新しいSSLContextオブジェクトを取得して、そのSSLContextオブジェクトから取得したSSLSocketまたはSSLEngineオブジェクトがプロパティ設定を反映するようにする必要があります。 1つの例外はjdk.tls.stapling.responseTimeoutプロパティです。 このプロパティは、ServerHandshakerオブジェクトが(基本的に、SSLSocketまたはSSLEngineオブジェクトの作成と同時に)の作成時に評価されます。

クライアント側の設定

¹クライアント側のOCSPフォールバックが発生するのは、ocsp.enableセキュリティ・プロパティがtrueに設定されている場合のみです。

開発者は、OCSPプルで提供された回答をどのように処理するかに柔軟性があります。 OCSPプルは、証明書のパス・チェックおよび失効チェックに関わる現在のメソッド論に変更を加えません。 つまり、クライアントとサーバーの両方がstatus_request拡張をアサートしたり、CertificateStatusメッセージを介してOCSPレスポンスを取得したり、失効情報への対応方法、またはその欠如をユーザーに柔軟に提供できます。

呼出し側からPKIXBuilderParametersが提供されない場合、失効チェックは無効になります。 呼出し側がPKIXBuilderParametersオブジェクトを作成し、setRevocationEnabledメソッドを使用して失効チェックを有効にすると、プルされたOCSPレスポンスが評価されます。 これは、com.sun.net.ssl.checkRevocationプロパティがtrueに設定されている場合にも当てはまります。

PKIのOCSPサポート

RFC 2560に定義されているOCSP (On-Line Certificate Status Protocol)のクライアント側サポートが提供されています。

ocsp.responderURL=http://ocsp.example.net:80

ocsp.responderCertSubjectName="CN=OCSP Responder, O=XYZ Corp"

ocsp.responderCertIssuerName="CN=Enterprise CA, O=XYZ Corp"

ocsp.responderCertSerialNumber=2A:FF:00

これらのプロパティは、Javaランタイムの<java_home>/conf/security/java.securityファイルで静的に設定することも、java.security.Security.setProperty()メソッドを使用して動的に設定することもできます。

デフォルトでは、OCSPチェックは有効ではありません。 有効にするには、ocsp.enableプロパティをtrueに設定します。 その他のプロパティは、オプションで使用できます。 OCSPチェックは、失効チェックも有効になっている場合にのみ有効になります。 失効チェックは、PKIXParameters.setRevocationEnabled()メソッドを介して有効化されます。

OCSPチェックは、失効チェック中に証明書失効リスト(CRL)と連動して機能します。 次は、OCSPとCRLの相互作用のサマリーです。 CRLでのフェイルオーバーは、OCSPに問題が発生した場合にかぎり、発生します。 OCSP応答者が、証明書が取り消されたことまたは取り消されていないことを確認した場合は、フェイルオーバーは発生しません。

最大許容クロック・スキュー

ネットワークが低速であるか、システム・クロックが一定時間オフになっているために、失効チェック中に接続障害が発生する場合があります。 システム・プロパティcom.sun.security.ocsp.clockskewを使用して、失効チェックに使用される最大許容クロック・スキュー(レスポンス時間とローカル時間の時間差)を秒単位で設定します。 このプロパティが設定されていないか、負の値の場合は、デフォルト値の900秒(15分)に設定されます。