Несколько хранилищ ключей Java

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

Сертификаты Windows ведут себя аналогичным образом: по умолчанию отображаются личные данные. хранилище для текущего пользователя. Новые закрытые ключи или доверенные сертификаты повлияют только на текущего пользователя, но машина по-прежнему будет иметь параметры по умолчанию, с которыми была поставлена ​​Windows (и каждое обновление будет изменять эти значения по умолчанию, как новый CA или ненадежные).

Что делает пользователь, должно не влияют на других пользователей на том же компьютере.

Что касается JRE и JDK, первый предназначен для , работающей среды (то есть для стандартного использования приложений), тогда как второй предназначен для разработка и имеет разные потребности. Сервер приложений будет нуждаться в JDK, так как ему необходимо «компилировать» страницы вроде *. Jsp и тому подобное на лету. JDK включает в себя собственную JRE, поэтому у него есть собственная копия всего, что JRE нужно для работы. Поскольку вам может потребоваться обеспечить поддержку клиентов (пользователей) иначе, чем для сервера (т.е. JRE и JDK могут использовать разные версии), совместное использование общих частей может помешать.

Вы можете изменить хранилище ключей (имя и расположение) с -keystore file.jks в той же команде, которую вы ввели, но вам нужно будет ссылаться на тот же файл в любой другой команде или конфигурации, чтобы java могла использовать это же хранилище ключей. Поскольку вы назвали псевдоним tomcat , я предполагаю, что вы будете использовать его в качестве хранилища ключей для сервера приложений, поэтому в файле server.xml (или catalina.xml) вам нужно будет настроить местоположение хранилища ключей.

Хранилища ключей для сервера должны находиться в каталоге с ограниченным доступом (доступном для чтения только пользователю, с которым работает сервер), например, / etc / ssl / и т.п.

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

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