Cisco ACE XML ゲートウェイ インストレーション アドミニストレーションガイド Software Version 5.1
管理通信にハードウェアベースの鍵を使用する方法
管理通信にハードウェアベースの鍵を使用する方法
発行日;2012/02/07 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 597KB) | フィードバック

管理通信にハードウェアベースの鍵を使用する方法

概要

  • ACE XML Manager は、Gateway との間で SSL 接続を確立してポリシーを実施する場合またはその他の管理機能を実行する場合に、X.509 クライアント証明書を提示し、Gateway がこれに自身のサーバ証明書で応答することを求めます。ACE XML Manager はさらに、証明書を使用して ACE XML Manager 監査ログに署名し、記録された情報の完全性を保証します。
  • セキュリティを強化するには、これらの目的にデフォルトの証明書ではなく、独自の証明書を使用する必要があります。各 X.509 証明書の固有のアイデンティティは、一連の PKI 鍵に基づいて決まります。初期設定時に新しい証明書をインストールする以外に、定期的に、またはセキュリティ侵犯の発生に備えて、新しい鍵をインストールすることもできます。
  • 証明書では、ソフトウェアベースまたはハードウェアベースの暗号鍵を使用できます。ACE XML システムでは、ソフトウェアベースの鍵を使用して、デフォルトの機能を実装します。セキュリティを強化するには、ハードウェアベースのキーストアによって生成され、保護された鍵に基づく証明書を使用できます。
  • ハードウェアベースの鍵を使用するには、ACE XML アプライアンスに nCipher ハードウェアベース キーストアを装備し、それらを使用するようにアプライアンスを設定する必要があります。「ハードウェア キーストアおよびセキュリティ ワールドの使用」を参照してください。
  • 最大限のセキュリティを確保するには、ハードウェアベースの鍵を推奨しますが、組み込み鍵をソフトウェアベースの鍵に置き換えることもできます。通常、組み込み鍵をハードウェアベースの鍵に置き換える場合も、ソフトウェアベースの鍵に置き換える場合も、手順はほぼ同じです。この章では、両者の手順が異なる場合には、ソフトウェアベースの鍵をインストールする場合の相違点についても明記します。

ハードウェアベースの証明書のインストール

  • ハードウェアベースの鍵を使用して双方向認証を行うように ACE XML アプライアンスを設定するプロセスは、2 つの手順からなります。
  • クラスタの各 Gateway に新しいサーバ証明書をインストールし、Gateway が双方向認証用にこの証明書を提示することを ACE XML Manager に通知する必要があります。
  • ACE XML Manager に新しいクライアント証明書をインストールし、ACE XML Manager が双方向認証用にこの証明書を提示することをクラスタの各 Gateway に通知する必要があります。
  • インストール手順は考え方としては似ていますが、細部は多少異なります。正しくインストールするために、必ず、各セクションの手順を 1 つひとつ慎重に実行してください。
  • 個々のハードウェアベースの証明書をインストールするには、ACE XML Manager アプライアンス上で特定のコマンドを実行し、Gateway アプライアンス上でまた別のコマンドを実行する必要があります。Gateway クラスタに双方向認証の証明書をインストールするには、クラスタの各 Gateway アプライアンス上で Gateway ベースのコマンドを実行する必要があります。

準備

  • 管理証明書で使用する鍵を変更する前に、次の前提条件が満たされていることを確認します。
  • 管理証明書に署名するために 1 つまたは複数の trusted CA(認証局)が使用できなければなりません。Manager と Gateway で同じ CA を使用する必要はありません。
  • 各 ACE XML アプライアンスを Gateway、Manager、または独立型マシンとして設定しておく必要があります。
  • 「ハードウェア キーストアおよびセキュリティ ワールドの使用」の手順に従って、nCipher セキュリティ ワールドを使用するように、各 ACE XML アプライアンスを設定しておく必要があります。
  • ハードウェアベースの SSL エンジンを使用可能にしておく必要があります。詳細については、 SSL アクセラレーションの有効化を参照してください。

Gateway から Manager への認証

  • 双方向認証にハードウェアベースの鍵を使用するように Gateway マシンを設定するには、次の作業が必要です。
  • 双方向認証で Gateway が提示する証明書に署名した CA を ACE XML Manager に通知します。
  • Gateway 上で Certificate Signing Request(CSR; 証明書署名要求)を作成します。
  • Gateway の trusted CA に CSR を送信し、Gateway のサーバ証明書に変換してもらいます。
  • Gateway にサーバ証明書をインストールします。
  • 各手順の詳細は、次のとおりです。
  • 作業を続ける前に、メッセージ トラフィックが設定対象の Gateway を迂回するようにしてください。それには、ネットワーク上で Gateway の手前にあるロードバランサで、Gateway をオフラインにします。Gateway をオフラインにしなかった場合は、手順の実行中に進行中のトランザクションが中断される可能性があります。また、アプライアンス シェルからすべての Gateway サービスを非アクティブに設定して停止させます(すなわち、 Network Configuration Cluster Configuration の順にメニュー項目を選択)。
  • ハードウェアベースの証明書を Gateway にインストールする手順は、次のとおりです。
ACE XML Manager マシン上で、 root ユーザとして bash を実行します。
  1. Gateway の trusted CA の自己署名ルート証明書のコピーを ACE XML Manager マシンの /usr/local/reactivity/private ディレクトリに保存します。
  2. ファイルは任意の方法でコピーできます。たとえば、Gateway の bash シェルから ACE XML Manager マシンに ssh を実行し、さらに scp コマンドを使用して CA 証明書をコピーできます。ここでは、この証明書を Gateway CA 証明書と呼びます。
  3. この Manager が制御するすべての Gateway が同じ Gateway CA 証明書を提出する必要があります。異なるシステム設定が必要な場合は、シスコのサポート担当者に問い合わせてください。Gateway と Manager で同じ CA を使用する必要はありません。しかし、双方向証明書交換の両者が同じ CA を使用しない場合は、最新の注意を払って、各マシンに正しい CA 証明書をインストールする必要があります。
  4. ACE XML Manager シェルで、次のディレクトリに移動します。
  5. cd /usr/local/reactivity
  6. 次のコマンドを実行して、trusted CA に関する ACE XML Manager の現在のデータベースをバックアップします。
  7. mv private/trustkeystore private/trustkeystore.bak
  8. このコマンドによって、 trustkeystore ファイルの名前が trustkeystore.bak ファイルに変更されます。 trustkeystore ファイルは、ACE XML Manager が信頼する CA のリストです。次のステップで、新しい trustkeystore ファイルを作成します。
  9. 次の例およびこの章の残りの部分では、1 行に収まらないコマンドは折り返して次の行に表示しています。バックスラッシュ( \ )は、このようにして折り返された行を意味します。 bash シェルにこれらの例(または独自のコマンド)を入力するときには、バックスラッシュを省いてください。
  10. ACE XML Manager シェルで次のコマンドを実行し、新しくインストールした Gateway CA 証明書に対応するエントリが指定された、新しい trusted CA データベースを作成します。

/usr/java/j2sdk1.4.2_04/bin/keytool \
-import -trustcacerts -alias ca_cert \
-keystore private/trustkeystore \
-storetype jks -file GCACERT.CRT \
-storepass approuter

  • この場合、 GCACERT.CRT は、インストールした Gateway CA 証明書のローカル コピーのファイル名です。
  • Trust this certificate? プロンプトに yes を入力します。
  • キーストアに新しい証明書が追加され、 Certificate was added to keystore メッセージが表示されます。
  • Gateway マシン上で、root ユーザとして bash を実行します。
  • コマンド プロンプトが表示されます。これ以降の手順では、この端末セッションを Gateway シェルと呼びます。
  • シェルで、次のディレクトリに移動します。
  • cd /usr/local/reactivity
  • 次のコマンドを実行し、Gateway の現在の管理サーバ証明書をバックアップします。
  • mv private/server.pem private/server.pem.bak
  • Gateway クラスタに証明書をインストールするには、クラスタの各 Gateway マシン上でこのような Gateway ベース コマンドを実行する必要があります。
  • Gateway シェルで、ハードウェアベースの鍵を使用するのか、それともソフトウェアベースの鍵を使用するのかに応じて、次のいずれかの手順を使用し、鍵と対応する CRS を作成します。
  • ハードウェアベースの鍵の場合
  • generatekey コマンドを実行し、Gateway 用の nCipher で保護される新しい秘密鍵と CSR を作成します。
  • /opt/nfast/bin/generatekey --batch embed \
    protect=module recovery=1 size=1024 \
    embedsavefile=private/server.pem \
    x509dnscommon="
    gatewayhost " \
    x509org="
    Reactivity " x509locality=" Belmont " \
    x509province="
    California " x509country=" US "
  • コマンドの中で、イタリック体のテキストは各自の状況に適した値に置き換えます。 x509dnscommon パラメータの値には、Gateway と通信するために ACE XML Manager が使用する完全修飾ホスト名を推奨しますが、絶対条件ではありません。
  • システムによって CSR が private/server_req.pem に書き込まれ、鍵生成処理に関する情報が表示されます。処理が正常に完了すると、出力の末尾に Key successfully generated が表示されます。
  • ソフトウェアベースの鍵の場合
  • generatekey コマンドの代わりに、次の 2 つのコマンドを入力します。
  • $ openssl genrsa -out server.pem 1024
    $ openssl req -key server.pem \
    -out server_req.pem -new -subj \
    "/CN=
    gatewayhost /OU= myorgunit /O= Reactivity
    /L= Belmont /ST= California /C= US "
  • コマンドの中で、イタリック体のテキストは各自の状況に適した値に置き換えます。CN の値には、Gateway と通信するために Manager が使用する完全修飾ホスト名を推奨しますが、絶対条件ではありません。
  • Gateway の trusted CA に CSR データ( server_req.pem ファイル)を送信し、署名入りの X.509 証明書に変換してもらいます。
  • CA は応答として、署名入り証明書を送信します。この証明書は Gateway のサーバ証明書であり、Gateway が ACE XML Manager に提示する証明書です。
  • CA から E メールの本文として署名入り証明書を受け取った場合は、証明書の内容だけをテキスト ファイルに保存します。
  • BEGIN CERTIFICATE の行全体から END CERTIFICATE の行全体までをすべて含めます。
  • ローカル ファイル システムで、有効な Linux ファイル名を使用してファイルを保存します。このファイル名にはスペース、アポストロフィ、アンパサンド、およびその他の特殊文字を使用しないでください。
  • Gateway シェルで、次のコマンドを実行し、署名入り証明書を Gateway にインストールします。
  • $ cat GCERT.CRT >> private/server.pem
  • 実際のコマンドでは、 GCERT.CRT を署名入り証明書のファイル名に置き換えます。
  • 必ず、出力リダイレクト演算子 >> を使用して、署名入り証明書を server.pem ファイルに付加してください。ファイルを置き換えると、 generatekey ツールでこのファイルに格納した秘密鍵が破壊され、キーストアで証明書が有効であるとは認識されなくなります。 このエラーからの復旧は不可能です。ここで説明したすべての手順を繰り返し、新しい鍵、新しい CSR、および新しい証明書を作成してインストールする必要があります。
  • すべての手順が正常に完了したら、この Gateway は両者間証明書交換にハードウェアベースの鍵を使用するように設定されたことになります。したがって、Gateway のハードウェアベースの管理証明書がインストールされ、ACE XML Manager が提示した証明書の検証に使用する CA が Gateway に通知された状態です。
  • これ以降、クラスタ内の他の Gateway を同様に設定できます。

Manager から Gateway への認証

  • 双方向認証にハードウェアベースの鍵を使用するように ACE XML Manager を設定するには、次の作業が必要です。
  • 双方向認証で ACE XML Manager が提示する証明書に署名した CA を ACE XML Gateway に通知します。この作業は、クラスタ内の各 ACE XML Gateway で実行する必要があります。
  • ACE XML Manager 上でハードウェアベースの鍵を使用する CSR を作成します。
  • Manager の trusted CA に CSR を送信し、Manager のクライアント証明書に変換してもらいます。
  • ACE XML Manager にクライアント証明書をインストールします。
  • ハードウェアベースの管理クライアント証明書を ACE XML Manager にインストールする手順は、次のとおりです。
作業を続ける前に、準備に記載されている前提条件が満たされていることを確認してください。
  1. この Manager が制御する各 Gateway マシンの次のディレクトリに、ACE XML Manager の trusted CA の自己署名ルート証明書のコピーを保存します。
  2. /usr/local/reactivity/private
  3. scp または任意のセキュア ファイル転送メカニズムを使用して、ファイルをコピーします。scp ユーティリティを使用する場合は、次のように、ACE XML Manager の bash シェルから実行し、ACE XML Manager の CA 証明書を Gateway マシンにコピーします。
  4. ssh gatewaymachine -l root
    cd /usr/local/reactivity/private
    scp root@manangername:/pathToMCACert/MCAERT.CRT
  5. この例では、 MCACERT.CRT ファイルは、ACE XML Manager が Gateway に提示する証明書に署名した CA の自己署名ルート証明書です。これ以後の手順では、この証明書を ACE XML Manager CA 証明書と呼びます。上記の例では、このファイルは pathToMCACert ディレクトリの managername コンピュータ上にあります。このファイルは 、scp コマンドによって、 gatewaymachine Gateway アプライアンスの
    /usr/local/reactivity/private
    ディレクトリにコピーされます。
  6. MCACERT.CRT ファイルは、双方向証明書交換で ACE XML Manager が提示する証明書に署名した CA の、PEM フォーマットの自己署名ルート証明書でなければなりません。Gateway と Manager は、それぞれに提示された証明書の検証に、両方で同じ CA を使用する必要はありません。しかし、双方向証明書交換の両者が同じ CA を使用しない場合は、各マシンに正しい CA 証明書をインストールするよう注意する必要があります。
  7. Gateway マシン上で、 root ユーザとして bash を実行します。
  8. Gateway シェルで次のコマンドを実行し、作業ディレクトリを最上位のディレクトリに移動します。
  9. cd /usr/local/reactivity
  10. Gateway シェルで次のコマンドを実行し、Gateway に現在インストールされている Manager CA 証明書をバックアップします。
  11. mv private/ca.crt private/ca.crt.bak
  12. このコマンドラインによって、 ca.crt ファイルの名前が ca.crt.bak ファイルに変更されます。このあと、新しい ca.crt ファイルをインストールします。
  13. Gateway シェルで次のコマンドを実行し、新しい Manager CA 証明書を Gateway にインストールします。
  14. cp MCACERT.CRT private/ca.crt
  15. MCACERT.CRT を、インストールした CA 証明書のローカル コピーのファイル名に置き換えます。
  16. Manager アプライアンス上で、 root ユーザとして bash を実行します。
  17. Manager シェルで、次のようにディレクトリを移動します。
  18. cd /usr/local/reactivity
  19. シェルで次のコマンドを実行し、Manager の現在のハードウェア鍵データベースをバックアップします。
  20. mv private/client.ncipher
    private/client.ncipher.bak
  21. このコマンドによって、 client.ncipher ファイルの名前が client.ncipher.bak に変更されます。このファイルには、Manager が管理する Gateway に接続するために Manager が使用するハードウェアベースの秘密鍵が保存されます。次のステップで、新しい client.ncipher ファイルを作成します。
  22. Manager シェルで次のコマンドを実行し、Manager の Web ベース インターフェイスが提示する証明書で使用する、nCipher によって保護される新しい秘密鍵を作成します。
  23. bin/ncipherkeytool -genkey -keystore private/client.ncipher -alias mykey -keyalg RSA -keysize 1024 -dname "CN= managerhostname , O= Reactivity ,L= Belmont ,ST= California ,C= US "
  24. CN O L 、および ST フィールドのイタリック体の値を各自の状況に適した値に置き換えます。特に CN= 値は、証明書をインストールする Manager マシンの完全修飾ホスト名にする必要があります。
  25. Manager シェルで次のコマンドを入力し、nCipher によって保護される新しい秘密鍵に基づいた CSR を作成します。
  26. bin/ncipherkeytool -certreq -keystore private/client.ncipher -alias mykey -file client.req
  27. システムによって CSR が client.req ファイルに書き込まれます。念のために、このファイルを調べ、有効な CSR が含まれていることを確認してください。
  28. Manager の trusted CA に CSR データ( client.req ファイル)を送信し、署名入りの X.509 証明書に変換してもらいます。
  29. この証明書は Manager のクライアント証明書であり、Manager が Gateway に提出する証明書です。
  30. CA から E メールの本文として署名入り証明書を受け取った場合は、証明書の内容だけをテキスト ファイルにペーストします。
  31. BEGIN CERTIFICATE の行全体から END CERTIFICATE の行全体までをすべて含めます。
  32. ローカル ファイル システム上で、有効な Linux ファイル名を使用してファイルを保管します。このファイル名にはスペース、アポストロフィ、アンパサンド、およびその他の特殊文字は使用しないでください。
  33. Manager シェルで次のコマンドを実行し、nCipher で保護される Manager のキーストアに Manager の trusted CA 証明書をインストールします。
  34. bin/ncipherkeytool -import -trustcacerts \
    -keystore private/client.ncipher -alias ca_cert \
    -file
    MCACERT.CRT
  35. このコマンドを入力するときは、 MCACERT.CRT パラメータを、インストールした Manager CA 証明書のローカル コピーのファイル名に置き換えます。
  36. シェルから、処理の確認が求められます。次のような出力が表示されます。
  37. Owner: EMAILADDRESS=name@example.com,
    CN=Some CA, OU=Engineering, O="Beagle, Inc.",
    L=Belmont, ST=California, C=US Issuer:
    EMAILADDRESS=name@example.com, CN=Some CA,
    OU=Engineering, O="Beagle, Inc.", L=Belmont,
    ST=California, C=US Serial number: 0
    Valid from: Thu Dec 09 20:31:59 UTC 2004
    until: Wed Dec 09 20:31:59 UTC
    2009
    Certificate fingerprints:
    MD5: XX: hellip :XX
    SHA1: XX: hellip :XX
    Trust this certificate? [no]:
  38. Gateway と Manager は、それぞれに提示された証明書の検証に、同じ CA を使用する必要はありません。しかし、双方向証明書交換の両者が同じ CA を使用しない場合は、最新の注意を払って、各マシンに正しい CA 証明書をインストールする必要があります。
  39. Manager シェルで yes を入力し、この証明書を信頼することを確認します。
  40. シェルによってキーストアに新しい証明書が追加され、 Certificate was added to keystore メッセージが表示されます。
  41. Manager シェルで次のコマンドを実行し、Manager の nCipher キーストアに新しい Manager クライアント証明書をインストールします。
  42. bin/ncipherkeytool -import \
    -keystore private/client.ncipher \
    -alias mykey -file
    MCERT.CRT
  43. このコマンドを入力するときは、 MCERT.CRT パラメータを、CSR への応答として Manager の trusted CA が戻した署名入り X.509 証明書のローカル コピーのファイル名に置き換えます。
  44. ncipherkeytool コマンドによって Manager のクライアント証明書が正常にインストールされると、 Certificate reply was installed in keystore メッセージが表示されます。
  45. Manager の Web インターフェイスに新しいクライアント証明書を提示させるには、次の手順を実行します。
次の Manager プロパティ ファイルを開いて編集します。 /usr/local/reactivity/config/webapp.properties
次の行を
  • ssl.client.keystore=
    /usr/local/reactivity/private/client.p12
  • 次のように変更します。
  • ssl.client.keystore=
    /usr/local/reactivity/private/client.ncipher
次の行を
  • ssl.client.storetype=pkcs12
  • 次のように変更します。
  • ssl.client.storetype=ncipher.sworld
  • Manager シェルで次のコマンドを実行し、agateway を webapp.properties ファイルのオーナーおよびグループとして設定します。
  • chown agateway:agateway
    /usr/local/reactivity/config/webapp.properties
  • 次のコマンドを入力し、所有権が変更されたことを確認します。
  • ls -la /usr/local/reactivity/config
  • シェルによって、 config ディレクトリの内容が表示されます。次の出力では、 webapp.properties ファイルに割り当てられたオーナーおよびグループは agateway となっています。
  • -rw-r--r-- 1 agateway agateway 2874 Feb 8 00:34
    webapp.properties
  • これらの手順の完了後、Manager はハードウェアベースの鍵を双方向証明書交換に使用します。さらに、この Manager が制御するすべての Gateway を設定すると、Manager と Gateway は双方向認証に新しくインストールされたハードウェアベースの証明書を使用できるようになります。

ハードウェアベースの証明書のテスト

  • これまでの説明に従って Manager および Gateway を設定したあとで、Manager の Web コンソールでイベント ログを表示することによって、インストールをテストできます。イベント ログに移動するには、Manager が管理対象の各 Gateway に対して双方向証明書交換を実行し、ログ エントリを取得する必要があります。
  • Manager の Web コンソールにログイン後、Manager が Gateway クラスタ メンバにアクセスできなかったことを示す警告が Dashboard に表示されていないかどうかを確認します。図8-1 に例を示します。
到達不能な Gateway
 
  • インストール プロセスの他の部分を正しく完了しないまま、証明書を置き換えた場合、完全なインストールではなくても、Manager の Web コンソールにログインしたり、Manager や Gateway との端末セッションを確立したりできる場合があります。ハードウェアベース鍵をインストールする前に Gateway が正しく設定されていても、証明書のロードまたはキーストアの読み込みに関連するエラーが原因で、Gateway が正常に起動しない場合があります。このメッセージが表示された場合、Event Log を検証することによって、問題を特定できる可能性があります。
  • Event Log を表示し、ハードウェア キーストア関連の問題またはその他の起動時の問題を示す Notice Warning 、または Alert メッセージを確認します。
  • Event Log にエントリを入力するために、ポーリングによって新しいイベントを検出し、ログに入力する前提条件として、Manager はクラスタ内の各 Gateway と双方向証明書交換を実行する必要があります。したがって、 Notice レベルまたはそれより上のレベルの Event Log を表示し、その中に証明書、ハードウェア キーストア、または Manager と対応する Gateway クラスタ間の通信に関連する問題が含まれていない場合は、双方向証明書交換に使用されるハードウェアベースの証明書は、正しくインストールされていることになります。

監査ログ署名クレデンシャルの変更

  • Console Audit Log は、ACE XML Manager Web コンソール ページであり、ポリシーの展開、現在のポリシーに関する変更、管理アカウントのユーザ権限に関する変更など、システムに影響を与える管理レベルの変更が表示されます。監査ログには、行われた変更のほかに、だれがその変更を行ったかも示されます。
  • 監査ログでは、PKI クレデンシャルを使用し、プロセスを認証してから、プロセスに対して監査ログの編集および署名を許可します。ここでは、このクレデンシャルで通常使用されるソフトウェアベースの鍵の代わりに、ハードウェアベースの鍵を使用する方法について説明します。
  • 作業を開始する前に、次の準備が必要です。
  • ハードウェアベース SSL エンジンを使用可能にします。詳細については、 SSL アクセラレーションの有効化を参照してください。
  • nCipher セキュリティ ワールドに ACE XML アプライアンスを追加します。
  • 監査ログ署名クレデンシャルを変更するには
Manager マシン上で、 root ユーザとしてアプライアンス シェルにログインします。
  1. メニューから Manage ACE XML Gateway Processes を選択します。
  2. Manage ACE XML Gateway Processes メニューで Stop ACE XML Manager を選択します。
  3. ACE XML アプライアンスによって Manager プロセスがシャットダウンされ、この処理が正常に実行されたことを示すステータス画面が表示されます。
  4. Enter キーを押して、ステータス画面を閉じます。
  5. Manage ACE XML Gateway Processes メニューで Return to Main Menu を選択します。
  6. Main Menu から Advanced Options を選択します。
  7. Advanced Options メニューから Run bash を選択します。
  8. bash コマンド プロンプトで、次のディレクトリに移動します。
  9. cd /usr/local/reactivity
  10. 監査ログ署名用の新しい nCipher 保護キーストアと自己署名証明書を作成するために、次のコマンドを実行します。
  11. $ bin/ncipherkeytool -genkey
    -keystore private/auditlog.ncipher
    -alias client -keyalg RSA -keysize 1024
    -dname "CN=auditlog"
  12. コマンドが正常に実行されたことを確認するには、 /usr/local/reactivity/private ディレクトリの内容を表示し、新しく作成された auditlog.ncipher ファイルが存在しているかどうかを確認します。たとえば、次のコマンドを使用できます。
  13. ls -lt private
  14. 次のコマンドを入力し、現在の監査ログ証明書をバックアップします。
  15. $ mv private/auditlog.crt private/auditlog.crt.bak
  16. このコマンドによって、 auditlog.crt の名前が auditlog.crt.bak に変更されます。処理を確認するために、 private ディレクトリの内容を表示します。名前変更の処理が正常に完了した場合は、このディレクトリに auditlog.crt.bak ファイルが存在し、 auditlog.crt ファイルは存在しません。
  17. 次のコマンドを実行し、ログ検証ユーティリティに使用させる新しい監査ログ証明書をキーストアから抽出します。
  18. $ bin/ncipherkeytool -export -rfc
    -keystore private/auditlog.ncipher
    -alias client -file private/auditlog.crt
  19. Certificate stored in file <private/auditlog.crt> メッセージが表示されます。
  20. /usr/local/reactivity/config/webapp.properties を次のように編集します。
次の行の p12 ncipher に変更します。
  • audit.log.private.key.pcks12=
    /usr/local/reactivity/private/auditlog.p12
  • 次のように変更します。
  • audit.log.private.key.pcks12=
    /usr/local/reactivity/private/auditlog.ncipher
次の行の pkcs12 ncipher.sworld に変更します。
  • audit.log.signing.keystore.type=pkcs12
  • 次のように変更します。
  • audit.log.signing.keystore.type=ncipher.sworld
  • Manager シェルで次のコマンドを実行し、 agateway webapp.properties のオーナーおよびグループとして設定します。
  • chown agateway:agateway
    /usr/local/reactivity/config/webapp.properties
  • 次のコマンドを実行し、 webapp.properties ファイルに割り当てられたオーナーおよびグループを表示して、ファイル所有権の変更を確認します。
  • ls -la /usr/local/reactivity/config
  • シェルによって、 config ディレクトリの内容が表示されます。次の出力では、 webapp.properties ファイルに割り当てられたオーナーおよびグループは agateway となっています。
  • -rw-r--r-- 1 agateway agateway 2874 Feb 8 00:34
    webapp.properties
  • 次のコマンドを入力し、監査ログの署名状態をリセットします。
  • $ rm auditlogs/audit.console.current
  • このコマンドによって、現在の監査ログが削除されます。以降の手順で、ハードウェアベース証明書で署名された新しい監査ログを作成します。
  • bash シェルを終了します。
  • Advanced Options メニューで Return to Main Menu を選択します。
  • メニューから Manage ACE XML Gateway Processes を選択します。
  • Start ACE XML Manager を選択します。
  • ACE XML アプライアンスによって Manager プロセスの再起動が試行され、この処理の状況を示すステータス画面が表示されます。
  • Enter キーを押して、ステータス画面を閉じます。
  • Manage ACE XML Gateway Processes メニューが再表示されます。
  • (アプライアンスのシェルではなく)ACE XML Manager Web コンソールに、管理者の役割が与えられたユーザとしてログインします。
  • Dashboard が表示されます。
  • Reports and Tools > Event Log リンクをクリックします。
  • Event Log に次のメッセージが表示されます。
  • A "/usr/local/reactivity/auditlogs/audit.console.current" not found. This file should only be missing on newly installed ACE XML Manager web consoles.
  • 前の手順で audit.console.current ファイルを削除したので、これは予期されたエラー メッセージです。削除したファイルの代わりに、ACE XML Manager が新しいログ ファイルを書き込むので、以後はログイン時にこのメッセージが表示されることはありません。
  •