Caché での SSL/TLS の使用法

証明書に必要な情報

クライアントがサーバを認証する場合、クライアントには、サーバ独自の証明書から、サーバの信頼された CA 証明書まで、これらの間にあるものすべてを含む完全な証明書チェーンが必要です。

サーバ SSL 構成を設定するときに、サーバの信頼された CA 証明書がルート証明書ではない場合、問題があります。認証を適切に機能させるために、クライアントでは、サーバの個人証明書から信頼された自己署名 CA 証明書への証明書チェーンを構成するすべての証明書へのアクセスを必要とします。このチェーンはサーバの証明書ファイル (ハンドシェイク時に送信されたもの) とクライアントの信頼された CA 証明書ファイルの組み合わせから得られます。信頼された自己署名ルート CA 証明書はクライアントの CA 証明書ファイルに入っている必要があります。また、サーバの個人証明書はサーバの証明書ファイルの先頭エントリでなければなりません。その他の証明書は、これらの 2 つの場所に分けることができます。クライアントがサーバに対して認証を実行するときには、同じ制約が逆に適用されます。

証明書の形式に関しては、Windows 証明書エクスポート・ウィザードからの証明書は、既定の DER でエンコードされたバイナリ X.509 でなく、Base 64 でエンコードされた X.509 形式である必要があります。

暗号スウィート構文の有効化

構成は、有効な暗号スウィートを使用する接続のみを許可します。有効な暗号スウィートを指定するには、以下のいずれかを実行します。

• 各暗号スウィートの名前を使用して暗号スウィートのリストを作成します。

• OpenSSL 構文を使用して、暗号スウィートの有効および無効を指定します。

暗号スウィートの名前のリストと有効な暗号スウィートを指定する構文については、openssl.org の "ciphers(1) のマニュアル・ページOpens in a new tab" に説明があります。この構文を使用すれば、構成に対してさまざまな機能やアルゴリズムを使用する場合の必要事項や禁止事項のガイドラインを指定できます。

Caché 構成での暗号スウィートの既定値は、ALL:!aNULL:!eNULL:!EXP:!SSLv2 です。これは、コロンで区切られた文で以下のグループに分けられます。

• ALL — eNULL 暗号以外のすべての暗号スウィートを含めます。

• !aNULL — 認証を提供しない暗号を除外します。

• !eNULL — 暗号化を提供しない暗号を除外します。

• !EXP — エクスポート承認済みアルゴリズム (40 ビットおよび 56 ビット) を除外します。

• !SSLv2 — SSL v2.0 暗号スウィートを除外します。

SSL/TLS を使用する Caché クライアント・アプリケーションに関するメモ

一部の動作については、Caché スーパーサーバと対話するクライアント・アプリケーションのサポートに Caché インスタンスを使用できます。例えば、シャドウ接続の保護に SSL/TLS を使用する場合、シャドウの宛先の役割を果たす Caché インスタンスは SSL/TLS クライアントになります。

SSL/TLS を使用して Caché スーパーサーバと対話するクライアント・アプリケーションを使用する場合は、構成について、次の点に特に注意してください。

• [構成名] — クライアントの名前には制限はありませんが、接続を構成するためにはこの情報は必須です。

• [タイプ] — インスタンスは SSL/TLS クライアントと共にサービスを提供するので、[タイプ] には [クライアント] を指定する必要があります。

• [暗号スウィート] — 指定された暗号スウィートは、サーバにより要求または指定されたものと一致する必要があります。

また、“必須証明書チェーンの確立” のセクションで説明しているように、クライアントとサーバは互いの証明書チェーンを検証できるように構成することも必要です。

構成ファイル、構成、プロパティ、値、および既定

各構成ファイルでは、1 つ以上の構成で使用するプロパティの値を指定します。このファイルには、名前と値のペアの形式で、既定値と構成固有の値の両方が記述されています。一般的にこのペアでは、バージョン管理していないプロパティの名前に対しては既定値を指定し、バージョン管理しているプロパティの名前に対しては構成固有の値を指定します。

構成ファイルに記述されている構成定義が 1 つのみの場合、構成側ではバージョン管理していないプロパティを使用できます。ただし、関連付けられた name プロパティを持つことはできません。名前付き構成を使用しない場合は、名前を指定せずに構成を呼び出します (“クライアント構成の使用の指定” および “名前なしでの構成の指定” を参照)。

構成ファイルに複数の構成がある場合は、構成のバージョン番号 n を付加して name.n の形式とした name プロパティを指定することで各構成を定義します。構成のその他のプロパティ名では、name プロパティと同じバージョン番号が使用されます。したがって、名前の形式は propertyname.n となります。ここで、propertyname にはプロパティの名前、n には構成の番号が入ります。

構成ファイル内の定義では、大文字と小文字は区別されます。スペースは自由に使用できます。また、プロパティ定義の順番も自由です。

すべての構成で使用されるプロパティの既定値を指定するには、バージョン管理されていないプロパティ名とその値を次の形式で指定します。

propertyName = propertyValue

例えば、keyStoreType プロパティの既定値を pkcs12 に指定するには、以下の形式とします。

keyStoreType = pkcs12

このプロパティの既定値より優先する値を使用するには、次のようにバージョン管理しているプロパティ名を指定します。

keyStoreType.1 = jceks

1 つの構成ファイルに複数の構成定義がある場合は、そのバージョン番号順に構成を使用する必要があります。クライアント・アプリケーション・コードで参照する構成番号が連続していない場合はエラーになります。例えば、ある構成ファイルにバージョン管理された 3 つの name プロパティ、name.1、name.2、および name.4 があるとします。この場合、name.4 プロパティに関連付けられている構成は作成されず、このプロパティへの参照は失敗し、エラーが表示されます。

Java クライアントの構成プロパティ

以下のようなプロパティがあります。

• cipherSuites — 暗号スウィートを、使用の優先順にコンマで区切って並べたリスト。使用可能な暗号スウィートは、使用しているマシン上の JRE (Java Runtime Environment) によって異なります。(省略可)

• debug — デバッグ情報を Java system.err ファイルに記録するかどうかを表します。このプロパティには true または false を指定できます (既定値は false)。このプロパティの設定は、例外処理に影響を与えません。(省略可)

• keyRecoveryPassword — クライアントの秘密鍵へのアクセスに使用されるパスワード。これは秘密鍵のペアと同時に作成されたものです。(秘密鍵がパスワードで保護されていて、アプリケーション・コードが入力パラメータとして秘密鍵に渡されない場合に必須)

• keyStore — クライアントの秘密鍵と証明書情報を格納するためのファイル。また、キーストアには、一般にトラストストアに関連付けられるコンテンツも格納できます。(省略可)

• keyStorePassword — キーストアにアクセスするためのパスワード。(キーストアの作成時にパスワードを指定した場合には必須)

• keyStoreType — キーストア・ファイルの形式が指定されている場合はその形式。(省略可)

  サポートされる形式は以下のとおりです。

  • jks — Java KeyStore。Java 独自の形式です。(既定)

  • jceks — Java Cryptography Extension KeyStore 形式。

  • pkcs12 — Public Key Certificate Standard #12 形式。

• logFile — Java がエラーの記録に使用するファイル。(省略可)

• name — バージョン管理している Java クライアント構成の識別子(各 name プロパティはバージョン管理する必要があります。バージョン管理していない name プロパティは意味がなく、無視されます)。

  構成ファイルで指定している構成が 1 つのみで、バージョン管理していないプロパティ名のみを使用している場合、name プロパティは必要ありません (“クライアント構成の使用の指定” を参照)。1 つの構成ファイルで複数の構成を指定する方法についての詳細は、“構成ファイル、構成、プロパティ、値、および既定” のセクションを参照してください。(省略可)

• protocol — (必須) 接続に使用される SSL または TLS プロトコル。指定されるオプションおよびプロトコルは以下のとおりです。

  • SSL — SSL のいずれかのバージョン。

  • SSLv3 — SSL バージョン 3。

  • TLS — TLS のいずれかのバージョン。(既定)

  • TLSv1 — TLS バージョン 1 (SSL バージョン 3.1 に相当)。

  • TLSv1.1 — TLS バージョン 1.1 (SSL バージョン 3.2 に相当)。

• trustStore — サーバのルート CA 証明書を格納するためのファイル。このファイルには、中間 CA の証明書も保持できます(この情報はキーストアに格納することもできます)。(省略可)

• trustStorePassword — トラストストアにアクセスするためのパスワード。(キーストアの作成時にパスワードを指定した場合には必須)

• trustStoreType — トラストストア・ファイルの形式が指定されている場合はその形式。(省略可)

  サポートされる形式は以下のとおりです。

  • jks — Java KeyStore。Java 独自の形式です。(既定)

  • jceks — Java Cryptography Extension KeyStore 形式。

  • pkcs12 — Public Key Certificate Standard #12 形式。

構成ファイルのサンプル

ここでは、Java クライアントで使用できる構成ファイルの例を示します。

debug = true
protocol = SSLv3
cipherSuites = SSL_RSA_WITH_RC4_128_MD5
keyStoreType = JKS
trustStore = ca.ts
trustStoreType = JKS

name.1 = CacheJavaClient1
keyStore.1 = cjc1.ks
keyStorePassword.1 = cjc1kspw123&XtraChar$
trustStore.1 = cjc1.ts
trustStorePassword.1 = cjc1tspw[+0therNo|sechars]

name.2 = CacheJavaClient2
keyStore.2 = cjc2.ks
keyStoreType.2 = pkcs12

name.3 = CacheJavaClient3
debug.3 = false
cipherSuites.3 = TLS_RSA_WITH_AES_128_CBC_SHA

構成ファイルの名前付け

構成ファイルは、SSLConfig.properties という名前で保存するか、Java 環境変数 com.intersys.SSL.ConfigFile の値をファイルの名前に設定します。コードは、現在の作業ディレクトリにあるファイルをチェックします。

DriverManager オブジェクトの使用法

DriverManager では、以下の手順を実行します。

1. Java Properties オブジェクトを作成します。

2. このオブジェクトの各種プロパティに値を設定します。

3. クライアントから Caché サーバへの接続のために、このオブジェクトを Java Connection オブジェクトに渡します。

接続で使用する情報を指定するには、まず構成ファイルから Properties オブジェクトを作成し、これに特定のプロパティの値を設定します。この処理を行うコードを最も簡単な形式で表すと、以下のようになります。

java.util.Properties prop = new java.util.Properties();
prop.put("connection security level", "10");
prop.put("SSL configuration name",configName);
prop.put("key recovery password",keyPassword);

各項目の内容は次のとおりです。

• 接続のセキュリティ・レベル 10 は、クライアントが SSL/TLS を使用して接続を保護しようとしていることを表します。

• configName は、Java クライアント構成の名前を値とする変数です。構成ファイルでは既定値のみを指定し、これらの既定値を 1 つの構成でのみ使用する場合は、この行を記述しないでください。詳細は、次の “名前なしでの構成の指定” のセクションを参照してください。

• keyPassword は、キーストアからクライアントの秘密鍵を抽出するために必要なパスワードです。

Properties オブジェクトが存在し、これに値が指定されると、最後の手順として Caché Java クライアントから Caché サーバへの接続にこのオブジェクトが渡されます。これは、DriverManager.getConnection メソッドへの呼び出しによって行われます。これを呼び出すための形式は次のとおりです。

Connection conn = DriverManager.getConnection(CacheServerAddress, prop);

ここで、CacheServerAddress は Caché サーバのアドレスを表す文字列、prop はこの文字列に渡される Properties オブジェクトです。

この呼び出しに成功すると、SSL/TLS で保護された接続が確立されます。通常、このセクションで説明したような呼び出しを含むアプリケーション・コードには、正常終了を確認するためのさまざまなチェック機構や、あらゆるエラーに対する保護が含まれます。Caché Java バインディングの使用に関する詳細は、"Caché での Java の使用法" を参照してください。

CacheDataSource オブジェクトの使用法

CacheDataSource オブジェクトを使用する際は、オブジェクトを作成し、そのメソッドを呼び出して関連値を設定し、接続を確立します。メソッドは以下のとおりです。

• setConnectionSecurityLevel — このメソッドは単一の引数 (接続のセキュリティ・レベル 10) を取ります。これは、クライアントが SSL/TLS を使用して接続を保護しようとしていることを表します。

• setSSLConfigurationName — このメソッドは単一の引数 (Java クライアント構成の名前を値とする変数) を取ります。構成ファイルでは既定値のみを指定し、これらの既定値を 1 つの構成でのみ使用する場合は、この行を記述しないでください。詳細は、次の “名前なしでの構成の指定” のセクションを参照してください。

• setKeyRecoveryPassword — このメソッドは単一の引数 (キーストアからクライアントの秘密鍵を抽出するために必要なパスワード) を取ります。

この処理を行うコードを最も簡単な形式で表すと、以下のようになります。

try{
   CacheDataSource ds = new CacheDataSource();
   
   ds.setURL("jdbc:Cache://127.0.0.1:1972/Samples");
   ds.setConnectionSecurityLevel(10);
   ds.setSSLConfigurationName(configName);
   ds.setKeyRecoveryPassword(keyPassword);

   Connection dbconnection = ds.getConnection();
}

プロパティの取得および設定のためのメソッドの全リストについては、"JDBC での Caché の使用法" の “Caché JDBC 準拠” の章、“CacheDataSource” のセクションを参照してください。com.intersys.jdbc.CacheDataSource の JavaDoc は <install-dir>/dev/java/doc/index.html の下にあります。

名前なしでの構成の指定

構成ファイルに記述されている構成定義が 1 つのみの場合、構成側ではバージョン管理していないプロパティを使用できます。ただし、関連付けられた name プロパティを持つことはできません。

DriverManager オブジェクトを扱う場合、Properties オブジェクトでは構成ファイルにある既定値のみを使用します。このオブジェクトを作成するコードは、“SSL 構成名” キーの値を指定する呼び出しがないという点で通常のオブジェクト作成コードとは異なります。

java.util.Properties prop = new java.util.Properties();
prop.put("connection security level", "10");
prop.put("key recovery password",keyPassword);

CacheDataSource オブジェクトを扱う場合、名前のない構成を指定するには、単に setSSLConfigurationName の呼び出しを行わないようにします。

ミラー・メンバ用 SSL/TLS 構成の作成

この構成を作成する手順は以下のとおりです。

1. Caché のインスタンスのミラーリングがまだ有効になっていない場合は有効にします。そのためには、%Service_Mirror サービスの [サービス編集] ページを使用し、このページで [サービス有効] チェック・ボックスにチェックを付けます。このページには、以下の 2 つのパスのいずれかから移動できます。

   • [ミラー設定] ページ ([システム管理]→[構成]→[ミラー設定]) で、[ミラーサービスを有効にする] を選択する。

   • [サービス] ページ ([システム管理]→[セキュリティ]→[サービス]) で、[%Service_Mirror] を選択する。

2. [ミラー用 SSL/TLS 構成の作成] ページに移動します。移動するには、[SSL/TLS 構成] ページ ([システム管理]→[セキュリティ]→[SSL/TLS 構成]) で [ミラー用構成の作成] をクリックするか、または [ミラーの作成] ページ ([システム管理]→[構成]→[ミラー設定]→[ミラーの作成]) で [SSL/TLS の設定] をクリックします。

3. [ミラー用 SSL/TLS 構成の作成] ページ ([システム管理]→[セキュリティ]→[SSL/TLS 構成]→[ミラー用 SSL/TLS 構成の作成]) で、フォームのフィールドにすべて入力します。このページのフィールドは、[新規 SSL/TLS 構成] ページのフィールドに似ています (“SSL/TLS 構成の作成または編集” のセクションを参照)。このページは、ミラーリングが自動的に有効になるサーバ構成とクライアント構成 (%MirrorClient と %MirrorServer) の両方を作成するため、[構成名]、[説明]、[有効] のいずれのフィールドもありません。また、秘密鍵パスワードに関しては、このページでパスワードの入力または置き換え ([新規パスワード入力])、パスワードを使用しないことの指定 ([パスワードクリア])、あるいは既存のパスワードをそのまま使用すること ([そのままにする]) の指定を行えます。

   両方の構成で同じ X.509 証明書が必要なため、このフォームの入力が完了すると両方の構成が同時に保存されます。このページのフィールドは以下のとおりです。

   • [信頼された証明書機関 X.509 証明書を含むファイル]

     Note:

     このファイルには、他のミラー・メンバに属する X.509 証明書の検証に使用できる証明書が含まれている必要があります。ファイルに複数の証明書が含まれている場合は、それらの証明書を正しい順序で (現在のインスタンスの証明書が最初になるように) 並べる必要があります。詳細は、"必須証明書チェーンの確立" を参照してください。

   • [この構成のX.509 証明書を含むファイル]

     Note:

     • 証明書の識別名 (DN) は証明書のサブジェクト・フィールドに表示する必要があります。

     • 使用する証明書に鍵用途か拡張鍵用途のエクステンションがある場合、次のセクションの “ミラー・メンバの証明書に関する特別な考慮事項” を参照してください。

   • [関連づけられた秘密鍵を含むファイル:]

   • [秘密鍵タイプ]

   • [パスワード]

     [そのままにする] を選択した場合、証明書に関連付けられた秘密鍵の新規パスワードの入力および確認を行うための 2 つの追加フィールドがページに表示されます。

   • [プロトコル]

   • [有効な暗号化スウィート]

   フォームの入力が完了したら [保存] をクリックします。

ミラー・メンバの構成に関する概要は、"Caché 高可用性ガイド" の “ミラーリング” の章にある “ミラーの作成” のセクションを参照してください。

ミラー・メンバ用 SSL/TLS 構成の編集

メンバの %MirrorClient 構成と %MirrorServer 構成の作成が済んでいる場合、それらの構成は [ミラー用 SSL/TLS 構成の編集] ページ ([システム管理]→[セキュリティ] > [SSL/TLS 構成] で [ミラー用構成の編集] をクリック) で編集できます。このページには、前のセクションで説明した [ミラー用 SSL/TLS 構成の作成] ページと同じフィールドが表示されます。

ミラー・メンバの証明書に関する特別な考慮事項

SSL/TLS をミラーリングで使用する場合、%MirrorClient と %MirrorServer の構成では、同じ証明書と秘密鍵を使用する必要があります。したがって、両方の構成で使用されている証明書は、サーバ証明書としてもクライアント証明書としても使用可能である必要があります。

SSL/TLS のクライアントまたはサーバに固有の証明書エクステンションがあります。ミラーリングで使用されている証明書は、両方 (クライアントおよびサーバとして) の使用が可能である必要があるため、これらエクステンションのいずれかが証明書にある場合、クライアントとサーバの両方のエクステンションが必要になります。例えば、これは鍵用途および拡張鍵用途エクステンションで当てはまります。鍵用途エクステンションがある場合、以下の両方を指定する必要があります。

• デジタル・シグニチャの鍵用途 (クライアント用)

• 鍵暗号化の鍵用途 (サーバ用)

同様に、拡張鍵用途エクステンションがある場合、以下の両方を指定する必要があります。

• クライアント認証の鍵用途

• サーバ認証の鍵用途

両方のエクステンションがある場合、それぞれが両方の値を指定する必要があります。もちろん、エクステンションがどちらもない場合も有効です。

証明書で 1 つの値のみ (クライアントまたはサーバ) を指定した場合、ミラーリングの SSL/TLS 接続は、以下のようなエラーにより失敗します。

error:14094413:SSL routines:SSL3_READ_BYTES:sslv3 alert unsupported certificate

このエラーを解消する方法は、証明書の入手方法によって次のように異なります。

• 自己署名証明書を使用している場合、これらの条件に従った (OpenSSL ライブラリなどによる) 新しい証明書を作成します。

• 商用認証機関ツール (Microsoft Certificate Services など) を使用している場合、これらの条件に従った新しい証明書を作成し、このツールを使用して証明書署名要求 (CSR) に署名します。

• 証明書を商用認証機関 (VeriSign など) から購入した場合、証明書がこれらの条件に従うことの要求を CSR と共に含めます。

クライアントから SSL/TLS で保護された TCP 接続を開く

このシナリオでは、Caché はクライアントの一部であり、TCP 接続は最初から SSL/TLS を使用します。　 以下はその方法です。

1. 使用する構成が利用できることを確認します。Caché を最後に起動したときよりも前に構成が作成された場合、その構成は有効化されて使用できる状態です。それ以外の場合は、新しい構成を作成したり、既存の構成を編集したりできます。

2. SSL/TLS を使用して TCP 接続を開きます。

クライアントとして機能する Caché は、クライアント・アプリケーションを介してサーバに接続します。この接続では指定した構成を使用して、SSL 関連の動作を決定します。

既存の TCP 接続への SSL/TLS の追加

このシナリオでは、TCP 接続が既に確立されていると仮定します。以下はその方法です。

1. 使用する構成が利用できることを確認します。Caché を最後に起動したときよりも前に構成が作成された場合、その構成は有効化されて使用できる状態です。それ以外の場合は、新しい構成を作成したり、既存の構成を編集したりできます。

2. SSL/TLS を使用して既存の TCP 接続を保護します。

SSL/TLS で保護されたソケットの構築

このシナリオでは、Caché はサーバとして動作して、TCP ソケットは最初から SSL/TLS を使用します。　 以下はその方法です。

1. 使用する構成が利用できることを確認します。Caché を最後に起動したときよりも前に構成が作成された場合、その構成は有効化されて使用できる状態です。それ以外の場合は、新しい構成を作成したり、既存の構成を編集したりできます。

2. SSL/TLS の使用が必要な TCP ソケットを開きます。

このソケットでは、ソケットと接続するクライアントの SSL/TLS を使用する必要があります。クライアントがサーバへの接続を試行すると、サーバでは SSL/TLS を使用する接続をネゴシエートしようとします。これが成功すれば、接続を正常に使用でき、ネゴシエートされたアルゴリズムで通信が保護されます。失敗すると、クライアントで接続を使用できません。

既存のソケットへの SSL/TLS の追加

このシナリオでは、TCP ソケットへの接続が既に確立されていると仮定します。以下はその方法です。

1. 使用する構成が利用できることを確認します。Caché を最後に起動したときよりも前に構成が作成された場合、その構成は有効化されて使用できる状態です。それ以外の場合は、新しい構成を作成したり、既存の構成を編集したりできます。

2. SSL/TLS を使用して、ソケットへの既存の TCP 接続を保護します。