Обновление сертификатов безопасности с другим центром сертификации

Откройте файл ES_PATH_CONF/elasticsearch.yml и проверьте имена и расположения хранилищ ключей, которые сейчас используются. Вы будете использовать те же имена для новых хранилищ ключей.

В этом примере хранилище ключей и хранилище доверенных центров сертификации используют разные файлы. Ваша конфигурация может использовать один и тот же файл как для хранилища ключей, так и для хранилища доверенных центров сертификации.

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

На любом узле вашего кластера сгенерируйте новый сертификат центра сертификации. Вам нужно выполнить этот шаг только один раз. Если вы используете сертификат центра сертификации своей организации, пропустите этот шаг.

./bin/elasticsearch-certutil ca --pem

На каждом узле вашего кластера импортируйте новый сертификат ca.crt центра сертификации в существующее хранилище доверенных центров сертификации. Этот шаг гарантирует, что ваш кластер доверяет новому сертификату центра сертификации. В этом примере используется утилита Java keytool для импорта сертификата в хранилище доверенных центров сертификации elastic-stack-ca.p12.

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

Проверьте, что новый сертификат центра сертификации был добавлен в хранилище доверенных центров сертификации.

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

При запросе введите пароль хранилища доверенных центров сертификации.

Вывод должен содержать как существующий сертификат центра сертификации, так и ваш новый сертификат. Если вы ранее использовали инструмент elasticsearch-certutil для генерации хранилища ключей, псевдоним старого центра сертификации по умолчанию ca, а тип записи — PrivateKeyEntry.

Используя новый сертификат и ключ центра сертификации, создайте новый сертификат для ваших узлов.

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

На текущем узле вашего кластера, где вы обновляете хранилище ключей, запустите поэтапную перезагрузку.

Остановитесь на шаге, где указано Выполните необходимые изменения, а затем переходите к следующему шагу этой процедуры.

Замените существующее хранилище ключей новым хранилищем ключей, убедившись, что имена файлов совпадают. Например, elastic-certificates.p12.

Если вам нужно сохранить новое хранилище ключей с новым именем файла, обновите файл ES_PATH_CONF/elasticsearch.yml, чтобы использовать имя файла нового хранилища ключей. Например:

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

(Необязательно) Используйте API сертификатов SSL для проверки того, что Elasticsearch загрузил новое хранилище ключей.

GET /_ssl/certificates

Если вы обновляете только сертификаты для транспортного уровня (а не уровня HTTP), выполните шаги с 2 по 6 по одному узлу за раз, пока вы не обновите все хранилища ключей в вашем кластере. Затем вы можете выполнить оставшиеся шаги для поэтапной перезагрузки.

В противном случае не выполняйте поэтапную перезагрузку. Вместо этого переходите к шагам по генерации нового сертификата для уровня HTTP.

(Необязательно) После замены хранилищ ключей на каждом узле вашего кластера, перечислите сертификаты в вашем хранилище доверенных центров сертификации, а затем удалите старый сертификат центра сертификации.

Если вы ранее использовали инструмент elasticsearch-certutil для генерации хранилища ключей, псевдоним старого центра сертификации по умолчанию ca, а тип записи — PrivateKeyEntry.

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

На любом узле вашего кластера, где установлен Elasticsearch, запустите инструмент сертификации Elasticsearch HTTP.

./bin/elasticsearch-certutil http

Эта команда сгенерирует файл .zip, содержащий сертификаты и ключи для использования с Elasticsearch и Kibana. В каждой папке находится файл README.txt, описывающий, как использовать эти файлы.

Разархивируйте сгенерированный файл elasticsearch-ssl-http.zip. Этот сжатый файл содержит одну директорию как для Elasticsearch, так и для Kibana. Внутри директории /elasticsearch находится директория для каждого узла с собственным файлом http.p12. Например:

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

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

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

На текущем узле вашего кластера, где вы обновляете хранилище ключей, запустите поэтапную перезагрузку.

Остановитесь на шаге, указывающем Выполните необходимые изменения, а затем переходите к следующему шагу в этой процедуре.

Замените ваше существующее хранилище ключей новым, убедившись, что имена файлов совпадают. Например, node1-http.p12.

Если вам нужно было сохранить новое хранилище ключей с новым именем файла, обновите файл ES_PATH_CONF/elasticsearch.yml, чтобы использовать имя нового хранилища ключей. Например:

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

Используйте API cat nodes для подтверждения, что узел присоединился к кластеру:

GET _cat/nodes

(Необязательно) Используйте API сертификатов SSL для проверки того, что Elasticsearch загрузил новое хранилище ключей.

GET /_ssl/certificates

Скопируйте файл elasticsearch-ca.pem в директорию конфигурации Kibana, как определено путем KBN_PATH_CONF.

Если вы изменили имя файла для файла elasticsearch-ca.pem, отредактируйте kibana.yml и обновите конфигурацию, чтобы указать расположение сертификата безопасности для HTTP-слоя.

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