Как узнать, какой файл склада доверенных сертификатов фактически загружен виртуальной машиной Java?

Question

Как узнать, какой файл склада доверенных сертификатов фактически загружен виртуальной машиной Java?

1

Как я могу программно найти файл java keystore, который использует мой JVM по умолчанию TrustManager?

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

Обновление: Вопрос: "Почему я не знаю? Ответ: мое приложение работает в среде клиента, которую я не контролирую, поэтому я не знаю.

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

Обновление: импульс, стоящий за этим вопросом, заключается в том, что я хочу отправить в свое приложение то, что нужно обновить хранилище ключей. Администратор, работающий с приложением, часто сталкивается с трудностями при определении правильного использования jvm, не говоря уже о правильном хранилище ключей. Я хочу дать подсказку администратору, какое хранилище данных они должны обновлять. Да, я знаю, что администратор должен "знать" много о Java и ключах, которых, вероятно, нет.

amb 29 авг. 2014, в 09:01

Источник

1

Почему ты уже не знаешь? Если вы не создали и не инициализировали свой собственный KeyManager , он может быть только тем, что задано системным свойством java.net.ssl.keyStore .
user207421 29 авг. 2014, в 06:39
0

@amb передайте это , но правильно сказал, что теперь вы должны настроить то, что настроили.
Ankur Singhal 29 авг. 2014, в 07:38
0

@ankur-singhal ankur-singhal Как Javadoc for KeyStore помогает идентифицировать хранилище ключей? Нет методов, которые бы сообщали вам, откуда взялся контент.
user207421 29 авг. 2014, в 09:44
0

Мало того, но одна JVM может использовать более одного хранилища ключей, даже миллионы, каждый из другого файла или не из какого-либо файла вообще (например, но не ограничиваясь PKCS # 11). Существует один файл хранилища доверенных сертификатов и, необязательно, один файл хранилища ключей (часто другой), используемый по умолчанию для соединений SSL или HTTPS , и вы можете найти их с небольшими усилиями, но их можно заменить или изменить с помощью кода. Если вы хотите знать, какой файл вы используете, самый простой подход - это явно использовать файл, который вы знаете.
dave_thompson_085 29 авг. 2014, в 10:43
0

@dave_thompson_085 dave_thompson_085 Существует хранилище доверенных сертификатов по умолчанию, но хранилища ключей по умолчанию вообще нет.
user207421 29 авг. 2014, в 23:54
0

@EJP, там установлен sysprop, это то, что я имел в виду под «опционально». В некоторых средах, которые я использую, значения sysprop настраиваются во многих местах, некоторые хорошо скрыты, что для практических целей является настройками по умолчанию, даже если они не выполняются непосредственно JVM.
dave_thompson_085 02 сен. 2014, в 07:32

Показать ещё 4 комментария

Теги:

java

file

keystore

1 ответ

Ещё вопросы

Почему ты уже не знаешь? Если вы не создали и не инициализировали свой собственный KeyManager , он может быть только тем, что задано системным свойством java.net.ssl.keyStore .
@amb передайте это , но правильно сказал, что теперь вы должны настроить то, что настроили.
@ankur-singhal ankur-singhal Как Javadoc for KeyStore помогает идентифицировать хранилище ключей? Нет методов, которые бы сообщали вам, откуда взялся контент.
Мало того, но одна JVM может использовать более одного хранилища ключей, даже миллионы, каждый из другого файла или не из какого-либо файла вообще (например, но не ограничиваясь PKCS # 11). Существует один файл хранилища доверенных сертификатов и, необязательно, один файл хранилища ключей (часто другой), используемый по умолчанию для соединений SSL или HTTPS , и вы можете найти их с небольшими усилиями, но их можно заменить или изменить с помощью кода. Если вы хотите знать, какой файл вы используете, самый простой подход - это явно использовать файл, который вы знаете.
@dave_thompson_085 dave_thompson_085 Существует хранилище доверенных сертификатов по умолчанию, но хранилища ключей по умолчанию вообще нет.
@EJP, там установлен sysprop, это то, что я имел в виду под «опционально». В некоторых средах, которые я использую, значения sysprop настраиваются во многих местах, некоторые хорошо скрыты, что для практических целей является настройками по умолчанию, даже если они не выполняются непосредственно JVM.

user207421 · Answer 1 · 2014-08-31T06-54-00.000Z

Как я могу программно найти файл java keystore, который использует мой JVM по умолчанию TrustManager?

Он задается содержимым javax.net.ssl.trustManager, если установлено, в противном случае это файл lib/security/jssecacerts в папке JRE, если он присутствует, в противном случае это файл lib/security/cacerts.

Все это указано в Справочном руководстве JSSE.

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

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

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