同じCAで証明書を更新する

この手順では、元々生成されたCA証明書とキーにアクセスできることを前提としています（または、あなたの組織が保持している）および現在使用中のノード証明書に署名するために使用されました。また、HTTPレイヤーでElasticsearchに接続するクライアントがCA証明書を信頼するように構成されていることも前提としています。

既存の証明書に署名したCAにアクセスできる場合は、クラスター内の各ノードの証明書とキーを置き換えるだけで済みます。各ノードで既存の証明書とキーを置き換え、同じファイル名を使用すると、Elasticsearchはファイルを再読み込みし、新しい証明書とキーを使用し始めます。

各ノードを再起動する必要はありませんが、再起動すると新しいTLS接続が強制され、証明書を更新する際の推奨プラクティスです。したがって、以下の手順には、各証明書を更新した後のノード再起動が含まれています。

以下の手順では、トランスポートレイヤーとHTTPレイヤーの両方の新しいノード証明書とキーを生成するための手順を提供します。どちらのレイヤーの証明書を置き換える必要があるかは、証明書の有効期限によって異なる場合があります。


キーストアがパスワード保護されている場合、パスワードはElasticsearchのセキュア設定に保存され、かつパスワードを変更する必要がある場合は、クラスターでローリング再起動を実行する必要があります。また、Elasticsearchがノードが再起動される前にファイルを再読み込みしないように、キーストアのファイル名を変更する必要があります。

CAが変更された場合は、異なるCAでセキュリティ証明書を更新する手順を完了してください。

トランスポートレイヤー用の新しい証明書を生成する

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

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

Yaml

  1. xpack.security.transport.ssl.keystore.path: config/elastic-certificates.p12
  2.   xpack.security.transport.ssl.keystore.type: PKCS12
  3.   xpack.security.transport.ssl.truststore.path: config/elastic-stack-ca.p12
  4.   xpack.security.transport.ssl.truststore.type: PKCS12
  5.   xpack.security.transport.ssl.verification_mode: certificate
  • 2. 既存のCAを使用して、ノード用のキーストアを生成します。現在使用中の証明書に署名したCAを使用する必要があります。

Shell

  1. ./bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12

コマンドパラメータ

  • --ca <ca_file>
  • あなたの証明書に署名するために使用されたCAキーストアの名前。既存のCAを生成するためにelasticsearch-certutilツールを使用した場合、キーストア名はelastic-stack-ca.p12にデフォルト設定されます。
  • 2.1. 出力ファイルの名前を入力するか、elastic-certificates.p12のデフォルトを受け入れます。
  • 2.2. プロンプトが表示されたら、ノードキーストアのパスワードを入力します。
    • 3. ノードキーストアを作成する際に現在のキーストアパスワードとは異なるパスワードを入力した場合、次のコマンドを実行してElasticsearchキーストアにパスワードを保存します:

Shell

  1. ./bin/elasticsearch-keystore add xpack.security.transport.ssl.keystore.secure_password
  • 4. キーストアを更新しているクラスター内の現在のノードで、ローリング再起動を開始します。
    必要な変更を行うというステップで停止し、この手順の次のステップに進みます。
  • 5. 既存のキーストアを新しいキーストアに置き換え、ファイル名が一致することを確認します。たとえば、elastic-certificates.p12。
    キーストアパスワードが変更される場合、パスワードを更新する前にElasticsearchがファイルを再読み込みしないように、新しいファイル名でキーストアを保存します。
  • 6. 新しいファイル名でキーストアを保存する必要があった場合は、ES_PATH_CONF/elasticsearch.ymlファイルを更新して新しいキーストアのファイル名を使用します。たとえば:

Yaml

  1. xpack.security.transport.ssl.keystore.path: config/elastic-certificates.p12
  2.   xpack.security.transport.ssl.keystore.type: PKCS12
  3.   xpack.security.transport.ssl.truststore.path: config/elastic-stack-ca.p12
  4.   xpack.security.transport.ssl.truststore.type: PKCS12
  • 7. キーストアを更新したノードを起動します。
  • 8. (オプション) SSL証明書APIを使用して、Elasticsearchが新しいキーストアを読み込んだことを確認します。

Python

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

Js

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

Console

  1. GET /_ssl/certificates
  • 9. トランスポートレイヤーの証明書のみを更新している場合（HTTPレイヤーではない）、ステップ4からステップ8までを1ノードずつ完了し、クラスター内のすべてのキーストアを更新します。その後、ローリング再起動の残りの手順を完了できます。
    そうでない場合は、ローリング再起動を完了しないでください。代わりに、HTTPレイヤー用の新しい証明書を生成する手順に進んでください。

次は何ですか？

お疲れ様でした！トランスポートレイヤーのキーストアを更新しました。必要に応じてHTTPレイヤーのキーストアを更新することもできます。HTTPレイヤーのキーストアを更新しない場合は、すべて完了です。

HTTPレイヤー用の新しい証明書を生成する

KibanaやElastic言語クライアントなどの他のコンポーネントは、Elasticsearchに接続する際にこの証明書を検証します。

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

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

Shell

  1. ./bin/elasticsearch-certutil http

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

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

Txt

  1. /node1
  2.   |_ README.txt
  3.   |_ http.p12
  4.   |_ sample-elasticsearch.yml

Txt

  1. /node2
  2.   |_ README.txt
  3.   |_ http.p12
  4.   |_ sample-elasticsearch.yml

Txt

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

Yaml

  1. xpack.security.http.ssl.enabled: true
  2.   xpack.security.http.ssl.keystore.path: node1-http.p12
  • 8. キーストアパスワードが変更される場合、Elasticsearchのセキュア設定に秘密鍵のパスワードを追加します。

Shell

  1. ./bin/elasticsearch-keystore add xpack.security.http.ssl.keystore.secure_password
  • 9. キーストアを更新したノードを起動します。
    catノードAPIを使用して、ノードがクラスターに参加したことを確認します:

Python

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

Ruby

  1. response = client.cat.nodes
  2.   puts response

Js

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

Console

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

Python

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

Js

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

Console

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