В предыдущей статье мы запустили Kafka с аутентификацией посредством протокола SASL_PLAIN с механизмом PLAIN.

Настало время разобраться с SSL.

В этой статье мы подготовим все необходимое для последующей настройки соединения SSL в Kafka.

Предыдущая статья.Следующая статья.

SSL

Немного теории

Мы не будем детально рассматривать SSL. Отметим основные для нас вещи:

1. SSL формирует шифрованный канал между клиентом и сервером
2. Серверная сторона диалога всегда аутентифицируется перед клиентом. Т.е. клиент может проверить что сервер, тот за кого он себя выдает. Сервер тоже может проверить клиента, но это не обязательно.

Давайте разберем каким образом клиент проверяет что сервер является тем, за кого себя выдает. У сервера есть пара — открытый/закрытый ключ.

• Закрытым ключом сервер шифрует данные. Закрытый ключ находится только у сервера!
• Открытым ключом любой может зашифровать данные. Открытый ключ может распространяться свободно.
• Сервер отправляет публичный ключ клиенту

Сервер, является тем, за кого себя выдает в том случае, если у него есть верный приватный ключ. Если клиент не сможет расшифровать данные публичным ключом (соответствующим верному приватному ключу), то данные, отправленные сервером, зашифрованы не верным приватным ключом. И, скорее всего, эти данные отправила в канал третья сторона — злоумышленник, который не имеет верного приватного ключа!

Но, если сервер отправляет публичный ключ, то как же тогда определить, что сервер отправил верный публичный ключ? Ведь злоумышленник может отправить свой публичный ключ! Чтобы решить эту проблему публичный ключ выдается в виде сертификата. В сертификате указано кому он выдан (IP или доменное имя) и кем он выдан и подписан! Сертификаты бывают двух типов:

• Подписанные и выданные сертификационными центрами — в этом случае сертификаты выдаются специальными сертификационными центрами и подписываются ключами этих центров. Таким образом любой может проверить что данный сертификат выдан авторизованным центром для данного домена или IP.
• Самоподписные — когда сертификат выпускается вами же, в этом случае доверять такому сертификату другие не могут

Таким образом аутентификация происходит следующим образом:

1. Клиент запрашивает сертификат у сервера
2. Сервер отправляет сертификат с публичным ключом
3. Клиент проверяет что сертификат выдан авторизованным центром. Т.е. запрашивает сертификат авторизованного центра с публичным ключом и проверяет что сертификат сервера подписан ключом авторизованного центра.
4. Клиент проверяет что в сертификате указано имя сервера, к которому клиент обращается
5. Сервер отправляет шифрованные приватным ключом данные
6. Клиент расшифровывает данные публичным ключом

Где взять SSL сертификат

Если у Вас уже есть сертификат и приватный ключ то пропустите эту часть!

Из предыдущей части мы узнали, что нам нужен сертификат и приватный ключ сервера. Как мы уже знаем, сертификат должен быть выдан авторизованным центром. Однако, в целях разработки  часто пользуются самоподписным сертификатом. Т.е. выпускают его самостоятельно. Однако, проверить такой сертификат нельзя . Но этого вполне достаточно для проверки корректности настройки SSL.

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

Итак, выпустим сертификат и приватный ключ:

Следует отметить, что сертификат должен содержать либо поле CN с hostname, либо SAN c IP или HOSTNAME. Порядок сверки сертификата:

1. Берется имя или IP (в зависимости от того по IP обращались или по HOSTNAME) сервера
2. Если есть SAN, то сверяем с ним, если нет то hostname с CA

Таким образом, если Вы обращались по IP а сертификат содержит только HOSTNAME, то сертификат будет считаться невалидным!

Не забывайте заменять localhost на свой если необходимо. 

В результате у нас появятся два файла

• domain.pem — сертификат с публичным ключом
• domain.key — приватный ключ

Подготовим сертификат и приватный ключ к использованию в Kafka

У нас уже есть сертификат и приватный ключ. Казалось бы, можно на этом успокоиться. Однако, Kafka капризная и ей нужен свой формат сертификата и приватного ключа. А именно, Kafka поддерживает так называемые хранилища сертификатов в форматах JKS и PKCS12.

Хранилище сертификатов — это файл, который может в себе содержать ключи и сертификаты и шифруется паролем.

Итак, нам нужно два хранилища:

1. Для сервера c приватным и публичным ключом
2. Для клиента с публичным ключом

Создадим хранилища для клиента и сервера. Будем считать, что сертификат у нас в формате pem. Т.е. сертификат и приватный ключ создан, как описано в предыдущей части.

Сертификат в формате pem может также иметь расширения .pem, .crt, .cer, и .key. Что касается других форматов, то их можно конвертировать.

• DER в PEM
  
  openssl x509 -inform der -in certificate.cer -out certificate.pem

  1	openssl x509 -inform der -in certificate.cer -out certificate.pem

• P7B в PEM
  
  openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer

  1	openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer

• PFX в PEM
  
  openssl pkcs12 -in certificate.pfx -out certificate.cer -nodes

  1	openssl pkcs12 -in certificate.pfx -out certificate.cer -nodes

Создание хранилища сертификата и приватного ключа для сервера. Во время создания Вам нужно придумать и сохранить пароль для хранилища.

Создание хранилища сертификата для клиента. Во время создания Вам нужно придумать и сохранить  пароль для этого хранилища.

После выполнения всех команд у нас будут:

• server.keystore.p12 — хранилище сертификата и приватного ключа для сервера. И пароль к нему.
• client.truststore.jks — хранилище сертификата для клиента. И пароль к нему.

Резюме

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

В следующей статье мы узнаем, как настраивать протокол SSL для защиты канала без аутентификации в Kafka.

Предыдущая статья. Следующая статья.