Updating node security certificates - With a different CA - 《Elasticsearchガイドv8.15》日本語

異なるCAでセキュリティ証明書を更新する
トランスポート層の新しい証明書を生成する
クラスター内の各ノードの新しい証明書を生成する
次は何ですか？
HTTP層の新しい証明書を生成する
- Shell
- Txt
- Txt
- Txt
- Yaml
- Shell
- Python
- Ruby
- Js
- Console
- Python
- Js
- Console
次は何ですか？
KibanaとElasticsearch間の暗号化を更新する
- Yaml

異なるCAでセキュリティ証明書を更新する

新しいCAを組織から信頼する必要がある場合、または自分で新しいCAを生成する必要がある場合は、この新しいCAを使用して新しいノード証明書に署名し、ノードに新しいCAを信頼するよう指示します。

トランスポート層の新しい証明書を生成する

新しいCA証明書を作成するか、組織のCA証明書を取得し、それを既存のCAトラストストアに追加します。すべてのノードの証明書の更新が完了したら、古いCA証明書をトラストストアから削除できます（ただし、それ以前には削除しないでください！）。

以下の例ではPKCS#12ファイルを使用していますが、同じ手順がJKSキーストアにも適用されます。

1. ES_PATH_CONF/elasticsearch.ymlファイルを開き、現在使用中のキーストアの名前と場所を確認します。新しいキーストアには同じ名前を使用します。
この例では、キーストアとトラストストアは異なるファイルを使用しています。あなたの構成では、キーストアとトラストストアの両方に同じファイルを使用しているかもしれません。
これらの指示は、提供された証明書が信頼できるCAによって署名されており、検証モードがcertificateに設定されていることを前提としています。この設定により、ノードはホスト名の検証を試みないことが保証されます。

Yaml

xpack.security.transport.ssl.keystore.path: config/elastic-certificates.p12
  xpack.security.transport.ssl.keystore.type: PKCS12
  xpack.security.transport.ssl.truststore.path: config/elastic-stack-ca.p12
  xpack.security.transport.ssl.truststore.type: PKCS12
  xpack.security.transport.ssl.verification_mode: certificate

2. クラスター内の任意のノードで、新しいCA証明書を生成します。このステップは一度だけ完了すれば十分です。組織のCA証明書を使用している場合は、このステップをスキップしてください。

Shell

./bin/elasticsearch-certutil ca --pem

コマンドパラメータ

--pem
PKCS#12の代わりにPEM形式のCA証明書とキーを含むディレクトリを生成します。
2.1. 証明書とキーを含む圧縮出力ファイルの名前を入力するか、elastic-stack-ca.zipのデフォルト名を受け入れます。
2.2. 出力ファイルを解凍します。結果のディレクトリにはCA証明書（ca.crt）とプライベートキー（ca.key）が含まれています。
これらのファイルはCAのプライベートキーを含むため、安全な場所に保管してください。
- 3. クラスター内のすべてのノードで、新しいca.crt証明書を既存のCAトラストストアにインポートします。このステップにより、クラスターが新しいCA証明書を信頼することが保証されます。この例では、Java keytoolユーティリティを使用して証明書をelastic-stack-ca.p12 CAトラストストアにインポートします。

Shell

keytool -importcert -trustcacerts -noprompt -keystore elastic-stack-ca.p12 \
  -storepass <password>  -alias new-ca -file ca.crt

コマンドパラメータ

-keystore
新しいCA証明書をインポートするトラストストアの名前。
-storepass
CAトラストストアのパスワード。
-alias
キーストア内の新しいCA証明書エントリに割り当てたい名前。
-file
インポートする新しいCA証明書の名前。
- 4. 新しいCA証明書がトラストストアに追加されたことを確認します。

Shell

keytool -keystore config/elastic-stack-ca.p12 -list

プロンプトが表示されたら、CAトラストストアのパスワードを入力します。
出力には、既存のCA証明書と新しい証明書の両方が含まれているはずです。以前にelasticsearch-certutilツールを使用してキーストアを生成した場合、古いCAのエイリアスはcaにデフォルト設定され、エントリのタイプはPrivateKeyEntryです。

クラスター内の各ノードの新しい証明書を生成する

CAトラストストアが更新されたので、新しいCA証明書を使用してノードの証明書に署名します。

組織に独自のCAがある場合は、証明書署名要求（CSR）を生成する必要があります。CSRには、CAがセキュリティ証明書を生成して署名するために使用する情報が含まれています。

1. 新しいCA証明書とキーを使用して、ノードの新しい証明書を作成します。

Shell

./bin/elasticsearch-certutil cert --ca-cert ca/ca.crt --ca-key ca/ca.key

コマンドパラメータ

--ca-cert
PEM形式の新しいCA証明書（ca.crt）へのパスを指定します。--ca-keyパラメータも指定する必要があります。
--ca-key
CA証明書のプライベートキー（ca.key）へのパスを指定します。--ca-certパラメータも指定する必要があります。
1.1. 出力ファイルの名前を入力するか、elastic-certificates.p12のデフォルトを受け入れます。
1.2. プロンプトが表示されたら、ノード証明書のパスワードを入力します。
- 2. キーストアを更新しているクラスター内の現在のノードで、ローリング再起動を開始します。
  「必要な変更を行う」を示すステップで停止し、この手順の次のステップに進みます。
- 3. 既存のキーストアを新しいキーストアに置き換え、ファイル名が一致することを確認します。たとえば、elastic-certificates.p12。
  キーストアパスワードが変更される場合は、パスワードを更新する前にElasticsearchがファイルを再読み込みしないように、新しいファイル名でキーストアを保存します。
- 4. 新しいファイル名でキーストアを保存する必要がある場合は、ES_PATH_CONF/elasticsearch.ymlファイルを更新して新しいキーストアのファイル名を使用します。たとえば：

Yaml

xpack.security.transport.ssl.keystore.path: config/elastic-certificates.p12
  xpack.security.transport.ssl.keystore.type: PKCS12
  xpack.security.transport.ssl.truststore.path: config/elastic-stack-ca.p12
  xpack.security.transport.ssl.truststore.type: PKCS12

5. 更新したキーストアのノードを起動します。
6. (オプション) SSL証明書APIを使用して、Elasticsearchが新しいキーストアを読み込んだことを確認します。

Python

resp = client.ssl.certificates()
  print(resp)

Js

const response = await client.ssl.certificates();
  console.log(response);

Console

GET /_ssl/certificates

7. トランスポート層の証明書のみを更新している場合（HTTP層ではない）、クラスター内のすべてのキーストアを更新するまで、ステップ2からステップ6を1ノードずつ完了します。その後、ローリング再起動の残りのステップを完了できます。
そうでない場合は、ローリング再起動を完了しないでください。代わりに、HTTP層の新しい証明書を生成する手順に進みます。
8. (オプション) クラスター内の各ノードでキーストアを置き換えた後、トラストストア内の証明書をリストし、古いCA証明書を削除します。以前にelasticsearch-certutilツールを使用してキーストアを生成した場合、古いCAのエイリアスはcaにデフォルト設定され、エントリのタイプはPrivateKeyEntryです。

Shell

keytool -delete -noprompt -alias ca  -keystore config/elastic-stack-ca.p12 \
  -storepass <password>

コマンドパラメータ

-alias
トラストストアから削除したい古いCA証明書のキーストアエイリアスの名前。

次は何ですか？

よくやりました！トランスポート層のキーストアを更新しました。必要に応じて、HTTP層のキーストアを更新することもできます。HTTP層のキーストアを更新しない場合は、すべて完了です。

HTTP層の新しい証明書を生成する

新しいCA証明書とプライベートキーを使用してHTTP層の証明書を生成できます。KibanaやElasticの言語クライアントなどの他のコンポーネントは、Elasticsearchに接続する際にこの証明書を検証します。

組織に独自のCAがある場合は、証明書署名要求（CSR）を生成する必要があります。CSRには、CAが自己署名証明書の代わりにセキュリティ証明書を生成して署名するために使用する情報が含まれています。

クライアントを新しいCAを信頼するように更新する

HTTP層の新しい証明書を生成した後（使用する前に）、Elasticsearchに接続するすべてのクライアント（Beats、Logstash、任意の言語クライアントなど）に移動し、生成した新しいCA（ca.crt）を信頼するように構成する必要があります。

このプロセスは各クライアントで異なるため、証明書を信頼するためのクライアントのドキュメントを参照してください。この手順で必要な証明書を生成した後、KibanaとElasticsearch間のHTTP暗号化を更新します。

1. Elasticsearchがインストールされているクラスター内の任意のノードで、Elasticsearch HTTP証明書ツールを実行します。

Shell

./bin/elasticsearch-certutil http

このコマンドは、ElasticsearchとKibanaで使用する証明書とキーを含む.zipファイルを生成します。各フォルダーには、これらのファイルの使用方法を説明するREADME.txtが含まれています。

1.1. CSRを生成するかどうかを尋ねられたら、nと入力します。
1.2. 既存のCAを使用するかどうかを尋ねられたら、yと入力します。
1.3. 新しい CA証明書への絶対パスを入力します。たとえば、ca.crtファイルへのパスです。
1.4. 新しいCA証明書のプライベートキーへの絶対パスを入力します。たとえば、ca.keyファイルへのパスです。
1.5. 証明書の有効期限の値を入力します。有効期間を年、月、または日で入力できます。たとえば、1年の場合は1yと入力します。
1.6. 各ノードごとに1つの証明書を生成するかどうかを尋ねられたら、yと入力します。
各証明書には独自のプライベートキーがあり、特定のホスト名またはIPアドレスに対して発行されます。
1.7. プロンプトが表示されたら、クラスター内の最初のノードの名前を入力します。elasticsearch.ymlファイルのnode.nameパラメータの値として同じノード名を使用します。
1.8. 最初のノードに接続するために使用されるすべてのホスト名を入力します。これらのホスト名は、証明書のSubject Alternative Name（SAN）フィールドにDNS名として追加されます。
HTTPS経由でクラスターに接続するために使用されるすべてのホスト名とバリアントをリストします。
1.9. クライアントがノードに接続するために使用できるIPアドレスを入力します。
1.10. クラスター内の各追加ノードについてこれらの手順を繰り返します。
- 2. 各ノードの証明書を生成した後、プロンプトが表示されたらキーストアのパスワードを入力します。
- 3. 生成されたelasticsearch-ssl-http.zipファイルを解凍します。この圧縮ファイルには、ElasticsearchとKibanaの両方のための1つのディレクトリが含まれています。/elasticsearchディレクトリ内には、指定した各ノードのhttp.p12ファイルを持つディレクトリがあります。たとえば：

Txt

/node1
  |_ README.txt
  |_ http.p12
  |_ sample-elasticsearch.yml

Txt

/node2
  |_ README.txt
  |_ http.p12
  |_ sample-elasticsearch.yml

Txt

/node3
  |_ README.txt
  |_ http.p12
  |_ sample-elasticsearch.yml

4. 必要に応じて、各http.p12ファイルの名前をHTTPクライアント通信の既存の証明書の名前に一致させるように変更します。たとえば、node1-http.p12。
5. キーストアを更新しているクラスター内の現在のノードで、ローリング再起動を開始します。
「必要な変更を行う」を示すステップで停止し、この手順の次のステップに進みます。
6. 既存のキーストアを新しいキーストアに置き換え、ファイル名が一致することを確認します。たとえば、node1-http.p12。
キーストアパスワードが変更される場合は、パスワードを更新する前にElasticsearchがファイルを再読み込みしないように、新しいファイル名でキーストアを保存します。
7. 新しいファイル名でキーストアを保存する必要がある場合は、ES_PATH_CONF/elasticsearch.ymlファイルを更新して新しいキーストアのファイル名を使用します。たとえば：

Yaml

xpack.security.http.ssl.enabled: true
  xpack.security.http.ssl.keystore.path: node1-http.p12

8. キーストアパスワードが変更される場合は、Elasticsearchのセキュア設定にプライベートキーのパスワードを追加します。

Shell

./bin/elasticsearch-keystore add xpack.security.http.ssl.keystore.secure_password

9. 更新したキーストアのノードを起動します。
catノードAPIを使用して、ノードがクラスターに参加したことを確認します：

Python

resp = client.cat.nodes()
  print(resp)

Ruby

response = client.cat.nodes
  puts response

Js

const response = await client.cat.nodes();
  console.log(response);

Console

GET _cat/nodes

10. (オプション) SSL証明書APIを使用して、Elasticsearchが新しいキーストアを読み込んだことを確認します。

Python

resp = client.ssl.certificates()
  print(resp)

Js

const response = await client.ssl.certificates();
  console.log(response);

Console

GET /_ssl/certificates

11. 1ノードずつ、ステップ5からステップ10を完了し、クラスター内のすべてのキーストアを更新します。
12. ローリング再起動の残りのステップを完了し、「シャードの割り当てを再有効化する」ステップから始めます。

次は何ですか？

よくやりました！HTTP層のキーストアを更新しました。これでKibanaとElasticsearch間の暗号化を更新できます。

KibanaとElasticsearch間の暗号化を更新する

elasticsearch-certutilツールをhttpオプションで実行したとき、/kibanaディレクトリが作成され、elasticsearch-ca.pemファイルが含まれています。このファイルを使用して、KibanaがHTTP層のElasticsearch CAを信頼するように構成します。

1. elasticsearch-ca.pemファイルをKibanaの設定ディレクトリにコピーします。KBN_PATH_CONFにはKibanaの設定ファイルのパスが含まれています。アーカイブ配布（zipまたはtar.gz）を使用してKibanaをインストールした場合、パスはKBN_HOME/configにデフォルト設定されます。パッケージ配布（DebianまたはRPM）を使用した場合、パスは/etc/kibanaにデフォルト設定されます。
2. elasticsearch-ca.pemファイルのファイル名を変更した場合は、kibana.ymlを編集し、HTTP層のセキュリティ証明書の場所を指定するように設定を更新します。

Yaml

elasticsearch.ssl.certificateAuthorities: KBN_PATH_CONF/elasticsearch-ca.pem

3. Kibanaを再起動します。