Несколько сертификатов в хранилище ключей для проверки подлинности клиента Mysql SSL и настройки JMX через SSL

Мое приложение Java должно пройти аутентификацию в экземпляре Mysql облака Google с аутентификацией клиента SSL. Его клиентский ключ и сертификат предоставляются Google. Мне также необходимо настроить агент JMX с SSL в том же приложении, чьи сертификаты предоставлены частным CA.

Как предотвратить предоставление Mysql сертификата JMX и наоборот, если я добавлю оба частных сертификата в одно хранилище ключей, предоставленное JVM при запуске

Есть ли другой способ аутентификации сертификатов SSL с помощью Mysql, а затем в javax.net.ssl.keyStore? Если нет, существуют ли какие-либо псевдонимы, которые агент Mysql или JMX предпочитают над другими именами?

ОТВЕТЫ

Ответ 1

Вы можете посмотреть, используя сокет Cloud SQL MySQL factory, который использует временные SSL-сертификаты для аутентификации в Cloud SQL (поддерживается только для экземпляров Second Generation):

https://github.com/GoogleCloudPlatform/cloud-sql-mysql-socket-factory

Ответ 2

MySQL Безопасное подключение SSL

Для поддержки SSL для работы вы должны иметь следующее:

  • JDK, который включает JSSE (расширение Java Secure Sockets Extension), например JDK-1.4.1 или новее. SSL в настоящее время не работает с JDK, к которому вы можете добавить JSSE, например, JDK-1.2.x или JDK-1.3.x из-за следующей ошибки JSSE: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4273544

  • Сервер MySQL, который поддерживает SSL, был скомпилирован и настроен для этого, это MySQL 4.0.4 or later. Для получения дополнительной информации см. Создание MySQL с поддержкой безопасных подключений.

Клиентский сертификат (описанный в этом разделе)

Как работать с несколькими хранилищами ключей?

Сертификаты испытаний находятся в хранилищах ключей с именем node1.keystore … node100.keystore, которые были созданы в соответствии с шагами, описанными в Создание самоподписанных тестовых сертификатов.

  • Экспортируйте тестовый сертификат для node1.example.com:

    $ keytool -exportcert -keystore node1.keystore -alias node1 \
-storepass changeme -file node1.cer

  • Импортируйте сертификат теста в настраиваемый магазин доверия:

    keytool -importcert -keystore custom.truststore -alias node1 \
-storepass trustchangeme -file node1.cer -noprompt

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

  • Повторите шаги 1 и 2 для node2.keystore … node100.keystore.

Ссылка на ресурс:

Сведения о Keystore и Truststore:

Хранилище ключей используется одним из двух способов:

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

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

  • Hadoop TLS/SSL требует, чтобы доверительные и доверительные пароли хранились в открытом виде в файле конфигурации, который читается всеми.
  • Хранилища ключей и ключевые пароли хранятся в открытом виде в файле, который читается только членами соответствующей группы.

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

  • Keystores должен содержать минимальный набор ключей и сертификатов. Разумной стратегией было бы создать уникальное хранилище ключей для каждого хоста, которое будет содержать только ключи и сертификаты, необходимые службам Hadoop TLS/SSL, работающим на хосте. В большинстве случаев хранилище ключей должно содержать одну запись ключа/сертификата.

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

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

Важно: не используйте один и тот же пароль для магазинов доверия и ключей/ключей.

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