SSLキーおよび証明書の更新ガイドライン

サーバーが使用する証明書が期限切れになるか、有効でなくなった場合は、SSLキーおよび証明書を置き換えることが必要になることがあります。この項では、このタスクを完了するための手順について説明します。

以降の指示では、自己署名証明書および関連付けられるキー(Oracle NoSQL Databaseのデフォルト)について説明します。または、既存のデフォルト・セキュア・インストール用の外部証明書の構成ガイドラインで説明されているように、外部証明書を使用することもできます。

次の2つの方法のいずれかを使用して、SSLキーおよび証明書を更新できます:

plan update-tls-credentialsコマンドを使用します。
各SNで手動プロセスを使用して新しいSSLキーおよび証明書を作成し、トラストストア・エントリをマージし、store.keysファイルをセキュリティ・ディレクトリにコピーし、必要に応じてローリング再起動の一環として各SNを順番に停止および起動します。SNの再起動が必要となるのは、データ・ストアがまだOracle NoSQL Database 24.4以降に完全にアップグレードされていない場合のみとなりました。

planコマンドの使用

plan update-tls-credentialsコマンドは、データ・ストア内のストレージ・ノード・エージェント(SNA)で使用される共有TLS (Transport Layer Security、旧SSL)資格証明のセットに対する資格証明の更新を取得してインストールします。このプランは、すべてのSNAが同じ資格証明を共有するデータ・ストアでのみ使用し、ホスト固有の資格証明を持つデータ・ストアでは使用しないでください。

plan update-tls-credentials [-retrieve-only|-install-only] [-force]

planコマンドは、要件に応じて様々な方法で使用できます。

新しい資格証明を手動でコピーし、plan update-tls-credentialsコマンドを-install-onlyフラグとともに使用できます。これは、デフォルトで使用できる最良の選択肢です。
SSL資格証明およびキーの更新プロセス全体を自動化する必要がある場合は、オプションまたはフラグを指定せずにplan update-tls-credentialsコマンドを使用できます。そうすると、planコマンドによって資格証明が取得され、インストールされます。
資格証明を取得し、後でインストールする予定の場合は、plan update-tls-credentialsコマンドを-retrieve-onlyフラグとともに使用できます。

このplanコマンドを使用してSSLキーおよび証明書を自動的に更新する方法の詳細は、plan update-tls-credentialsを参照してください。

SSLキーおよび証明書の更新の手動プロセス

SSLキー/証明書の更新には、次のステップが含まれます。

ストレージ・ノードに新しいキー/証明書のペアを作成します。
新しいキー/証明書のペアをすべてのストレージ・ノードにコピーし、新しい証明書を既存のトラスト・ストア・ファイル(client.trustとstore.trust)にマージします。
必要に応じて、各ストレージ・ノードを順番に再起動します。SNを再起動する必要があるのは、データ・ストアがまだOracle NoSQL Database 24.4以降に完全にアップグレードされていない場合のみです。すべてのSNがアップグレードされると、再起動しなくてもキーおよび証明書の変更が認識されます。
マージされたエントリとともにclient.trustを各クライアントにコピーします。
マージされたエントリを含むstore.keysを各ストレージ・ノードにコピーし、各ストレージ・ノードを順番に再起動します(2回目)。このステップは、Oracle NoSQL Database 24.3以前を実行しているSNに対してのみ必要です。
すべてのストレージ・ノードのstore.trust内の古い証明書を削除します。
新しい証明書のみが使用されていることを確認します。

実行中のストアのSSLキーおよび証明書を更新するには、次のステップを実行します。Oracle NoSQL Databaseは、プロセス全体を通して操作可能なままにできます。

ノート:

次で使用されているOracle NoSQL Database環境は、容量が3、レプリケーション係数(RF)が3で3つのストレージ・ノードにデプロイされています。

セキュリティ構成ファイルの詳細は、セキュリティ構成を参照してください。

新しいSSLキー証明書の作成

1つ目のストレージ・ノード(SN1)で、キーを格納する一時ディレクトリを作成します。
```
cd /users/user_name/tmp/kvroot/  
mkdir newKey 
```
SN1で、securityconfigユーティリティを実行して、新しいディレクトリnewKeyに新しいキー/証明書ペアを作成します。新しい構成では、現在の構成と同じキーストア・パスワードを指定する必要があります。-kspwdオプションでパスワードを指定しない場合、ユーティリティによってパスワードの設定を求められます。
```
java -jar $KVHOME/lib/kvstore.jar securityconfig \
config create -root /users/user_name/tmp/kvroot/newKey  -kspwd 123456
```
```
cd /users/user_name/tmp/kvroot/newKey
ls -R security
```
出力:
```
./security:client.security
security.xml store.trust temp.cert client.trust store.keys store.wallet
./security/store.wallet:
cwallet.sso
```
SN1で、次のようにconfig merge-trustコマンドを使用してトラストストア・エントリをマージします。このコマンドの実行後は、client.trustファイルとstore.trustファイルに、2つのSSL証明書エントリが含まれるようになります。
```
java -jar $KVHOME/lib/kvstore.jar securityconfig \
config merge-trust  -root $KVROOT -source-root \
/users/user_name/tmp/kvroot/newKey
```
keytool -listを使用してキーストア内のエントリをリストします。
```
cd $KVROOT/security
keytool -list -keystore store.trust  
Enter keystore password: ********* 
```
出力:
```
Keystore type:
JKS Keystore provider: SUN
Your keystore contains 2 entries  
mykey_2, Feb 6, 2024,trustedCertEntry,  
Certificate fingerprint (SHA1):  
A3:75:F2:97:25:20:F9:AD:52:61:71:8F:6B:7E:B1:BB:E8:54:D1:7A  
mykey, Feb 6, 2024,trustedCertEntry,  
Certificate fingerprint SHA1):  
89:71:8C:F1:6D:7E:25:D7:AD:C4:7E:23:8C:09:0D:AC:CE:AE:3F:67
```
ノート:
client.trustファイルにも、前述のstore.trustファイルと同じ2つのエントリが含まれています。

複数ストレージ・ノード・デプロイメントでは、新しい構成(セキュリティ・ディレクトリとそのコンテンツ)を各ストレージ・ノード・ホストの新しい構成ディレクトリにコピーし、各ホストに対して、説明したとおりにmerge-trustを実行する必要があります。
SN2とSN3で、次のことを実行します:
```
cd /users/user_name/tmp/kvroot/  
mkdir newKey
```
ディレクトリnewKeyの内容をSN1からSN2とSN3の/users/user_name/tmp/kvroot/newKeyディレクトリにコピーします。
SN2とSN3で、次に示すようにconfig merge-trustコマンドを使用してトラストストア・エントリをマージします。
```
java -jar $KVHOME/lib/kvstore.jar securityconfig  \
config merge-trust -root $KVROOT \ 
-source-root /users/user_name/tmp/kvroot/newKey 
```
オプションで、keytoolコマンドを使用してSN2とSN3にあるキーストア内のエントリをリストできます(前述のSN1の場合と同様)。
自己署名証明書を使用して実行されているOracle NoSQL Databaseでは、クライアント側アプリケーションを、マージされたクライアント・トラストストアの使用に切り替えた後に、古い資格証明または新しい資格証明を使用してデータ・ストアに接続できます。更新手順のこの時点でクライアントに変更を加えることをお薦めします。これによって、クライアントが、更新プロセス全体にわたりそのデータ・ストアに接続できるようになります。マージされたエントリ(2つの証明書エントリ)を含むclient.trustファイルを各クライアントにコピーし、クライアント・アプリケーションで使用されている既存のclient.trustファイルを置き換える必要があります。更新が完了した後、クライアントで、古い証明書がクリアされるように、新しいトラストストアの使用に切り替える必要があります。
```
scp <SN1_host>:$KVROOT/security/client.trust \
<client_host>:<directory_client.trust>/client.trust
```
ノート:
client.trustは、クライアントとサーバー間の通信を認証する場合に使用し、store.trustは、サーバー間の通信を認証する場合に使用します。
各ストレージ・ノードを順番に停止し起動します。その際は、各SNが完全に起動されたことを確認してから次のSNを再起動してください。データ・ストアではSSL証明書を更新している間のストレージ・ノードの再起動中に定足数を維持する必要があるため、一度に1つのSNを再起動する必要があります。
再起動後に、そのストレージ・ノードで、マージされたstore.trustから新しい証明書と古い証明書が両方ロードされます。そのため、そのストレージ・ノードでは、新しいSSL資格証明と古いSSL資格証明を両方認識できます。まだ再起動されていないストレージ・ノードでは、引き続き、store.trustファイルからの古いSSL資格証明が使用されます。
各ストレージ・ノード(SN1、SN2およびSN3)で、次のステップを実行します:
```
java -jar $KVHOME/lib/kvstore.jar stop -root $KVROOT  
java -jar $KVHOME/lib/kvstore.jar start -root $KVROOT&
```
管理CLIを起動し、pingコマンドを使用して、すべてのレプリケーション・ノード(RN)が稼働中であることを確認します。
```
java -jar $KVHOME/lib/kvstore.jar runadmin -host $HOSTNAME -port 5000 \
-security $KVROOT/security/client.security 
```
匿名で管理にログインしました
```
kv-> ping
```
ノート:
SNを再起動する必要があるのは、データ・ストアがまだOracle NoSQL Database 24.4以降に完全にアップグレードされていない場合のみです。すべてのSNがアップグレードされると、再起動しなくてもキーおよび証明書の変更が認識されます。
store.keysファイルには、生成された秘密キーが含まれています。上で使用したmerge-trustユーティリティでは、store.trust内の証明書のみがマージされ、秘密キーはマージされません。NoSQL Databaseで新しいSSL秘密キーが使用されるようにするには、次に示すように、新しいstore.keysをすべてのストレージ・ノード内の$KVROOTの下のsecurityディレクトリにコピーする必要があります。
各ストレージ・ノード(SN1、SN2およびSN3)で、次のステップを実行します:
store.keysファイルをsecurityディレクトリにコピーし、ストレージ・ノードを停止してから再起動します。各ストレージ・ノードを、ローリング再起動として順番に停止し起動します。その際は、各SNが完全に起動されたことを確認してから次のSNを再起動してください。一度に1つのSNを再起動する必要があります。これは、データ・ストアでその再起動中に定足数を維持する必要があるためです。
```
cp /users/user_name/tmp/kvroot/newKey/security/store.keys $KVROOT/security/. 
java -jar $KVHOME/lib/kvstore.jar stop -root $KVROOT  
java -jar $KVHOME/lib/kvstore.jar start -root $KVROOT&
```
ノート:
SNを再起動する必要があるのは、データ・ストアがまだOracle NoSQL Database 24.4以降に完全にアップグレードされていない場合のみです。すべてのSNがアップグレードされると、再起動しなくてもキーおよび証明書の変更が認識されます。
各ストレージ・ノードで、廃止された証明書mykeyをstore.trustから削除します。その後、新しい証明書の名前mykey_2をmykeyに変更します。
各ストレージ・ノード(SN1、SN2およびSN3)で、次のステップを実行します:
mykeyという名前の古い証明書を削除します。
```
keytool -delete -keystore $KVROOT/security/store.trust -alias mykey  
Enter keystore password:  
```
新しく作成した証明書の名前mykey_2を、前のキーの名前であるmykeyに変更します。
```
keytool -changealias -keystore $KVROOT/security/store.trust \
-alias mykey_2 -destalias mykey
```
これで、mykeyという、新しく生成されたキー1つのみが存在するようになります。次のコマンドを使用して、その新しい証明書1つのみが示されることを確認します:
```
keytool -list -keystore $KVROOT/security/store.trust  
Enter keystore password:
```
```
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry  
mykey, Feb 6, 2024,trustedCertEntry,  
Certificate fingerprint (SHA1):  
A3:75:F2:97:25:20:F9:AD:52:61:71:8F:6B:7E:B1:BB:E8:54:D1:7A
```
これで、データ・ストア上のSSLキーおよび証明書が更新されました。

SSLキーおよび証明書の更新中の追加検証

データ・ストアのSSLキーおよび証明書を更新すると、次の追加チェックが実行されます。これらのチェックは、新しい資格証明に関する潜在的な問題を検出することを目的としています。

キーストアおよびトラストストア・ファイルのパスワードは、データ・ストアで現在使用中のキーストアおよびトラストストアのパスワードと同じである必要があります。
keystoreTypeおよびtruststoreTypeパラメータを使用して指定したキーストアおよびトラストストア・ファイルのタイプは、ファイルの正確なタイプと一致する必要があります。
キーストアには、keystoreSigPrivateKeyAliasパラメータを使用して指定した別名のエントリが必要です。この別名は、署名の作成に使用されるキー・ペアを識別します。このキー・ペアに対応する証明書は、トラストストア内の証明書で正常に検証される必要があります。この場合、キーストアとトラストストアには同じ証明書が含まれている必要がありますが、トラストストアには複数の証明書を含めることができます(たとえば、証明書チェーンの一部である場合)。
トラストストアには、truststoreSigPublicKeyAliasパラメータを使用して指定した別名のエントリが必要です。この別名は、署名の検証に使用される証明書を識別します。関連付けられた証明書が正常に検証され、キーストア内のkeystoreSigPrivateKeyAliasエントリの証明書と一致する必要があります。
キーストアには、任意のトランスポート・タイプに指定したすべてのserverKeyAliasパラメータのエントリが必要です。この別名は、ストア・サービスで使用されるキー・ペアを識別します。何も指定していない場合は、別名sharedが使用されます。このキー・ペアに対応する証明書は、トラストストア内の証明書で正常に検証される必要があります。

ノート:
トラストストアには、複数の証明書を含めることができます(たとえば、証明書チェーンの一部である場合)。また、キーストア証明書の検証では、トラストストア内に複数の証明書が必要になる場合もあります。
すべてのserverKeyAliasエントリは、関連するclientIdentityAllowedパラメータの検証要件を満たす必要があります(ある場合)。
パラメータclientAuthRequiredがtrueのトランスポートの場合、キーストアには、指定したすべてのclientKeyAliasパラメータのエントリが必要です。clientkeyAliasパラメータは、直接接続のJavaクライアントまたはプロキシで使用されるキー・ペアを識別します。何も指定していない場合は、別名sharedが使用されます。このキー・ペアに対応する証明書は、トラストストア内の証明書で正常に検証される必要があります。
すべてのclientKeyAliasentriesは、関連するserverIdentityAllowedパラメータの検証要件を満たす必要があります(ある場合)。