Проблема с хранилищем ключей и хранилищем доверенных сертификатов в сочетании сasticsearch и searchguard ssl - PullRequest
0 голосов
/ 17 марта 2019

Позвольте мне немного рассказать об истории вопроса, прежде чем я задам вопрос, чтобы у нас была ясность по самой проблеме.Нам нужно поддерживать односторонний SSL с Elasticsearch (v5.2.x), используя searchguard ssl.У нас есть список процедур для разработчиков (не для производства), который заботится о создании самозаверяющего сертификата SSL.Здесь у нас есть один корень (локально созданный) и фактический сертификат.Если мы импортируем хранилище ключей (содержащее закрытый ключ и подписанный сертификат) и доверенное хранилище (содержащее корневой сертификат), все работает нормально.

Но пару дней назад мы получили один запрос от клиента.Там в производстве нам нужно поддерживать SSL.Итак, мы выполнили следующие шаги:

  1. с помощью нашего скрипта, мы сгенерировали закрытый ключ, импортировали его в хранилище ключей, а также сгенерировали csr.

  2. Мы дали клиенту CSR.Он подписал его в надлежащем центре сертификации и вернул нам сертификат.

  3. Теперь цепочка доверия имеет длину 3 для данного сертификата.Итак, есть корневой ЦС, который подписал сертификат (isser1), который подписал сертификат (эмитент2), который, в свою очередь, подписал действительный csr.

  4. Для импорта действительного сертификата вхранилище ключей, мы импортировали всех трех родителей, а затем импортировали действительный сертификат.

  5. Затем мы удалили все родительские сертификаты из хранилища ключей.Итак, теперь в хранилище ключей есть только закрытый ключ и действительный сертификат.

  6. Мы импортировали все три родительских сертификата в хранилище доверенных сертификатов.

Теперь, если мы запустим Elasticsearch, выдается следующая ошибка: [ERROR][c.f.s.s.t.SearchGuardSSLNettyTransport] [uyyIg3i] SSL Problem Received fatal alert: certificate_unknown javax.net.ssl.SSLException: Received fatal alert: certificate_unknown

Забавно, точная процедура работает, если у нас есть только root ca, подписывающий фактический csr.Любая помощь будет полезна для выяснения первопричины этой проблемы, так как у меня сейчас нет идей.

1 Ответ

1 голос
/ 20 марта 2019

После нескольких утомительных сеансов отладки мы обнаружили, что CN-имя и фактическое имя хоста различаются. Сделав их одинаковыми, мы заработали.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...