Як дізнатися, який магазин брелоків використовує мій JVM?


125

Мені потрібно імпортувати сертифікат у свою сховище JVM. Я використовую наступне:

keytool -import -alias daldap -file somecert.cer

тому мені, мабуть, потрібно змінити свій дзвінок на щось подібне:

keytool -import -alias daldap -file somecert.cer -keystore cacerts storepass changeit

1
Вам потрібно імпортувати сертифікат до вашого довіреного магазину JVM , за винятком випадків , коли це підписаний CSR, і в цьому випадку вам слід імпортувати його у власну сховище ключів, і ви вже повинні знати, де це, інакше ви б не змогли створити клавіатура або КСВ.
Маркіз Лорн

Відповіді:


129

Ваша сховище ключів буде у вашому JAVA_HOME---> JRE -->lib---> security--> cacerts. Вам потрібно перевірити, де налаштовано ваш JAVA_HOME, можливо, одне з цих місць,

  1. Комп'ютер ---> Додатково -> Змінні середовища ---> JAVA_HOME

  2. Пакетні файли запуску вашого сервера.

У вашій команді імпорту -keystore cacerts (введіть повний шлях до вищевказаного JRE тут, а не просто кажуть).


6
/ Бібліотека / Java / Головна / lib / безпека / cacerts на Mac OS X 10.9
Сем Барнум

9
* "JAVA_HOME ---> JRE -> lib ---> security -> cacerts" Зверніть увагу на "s" наприкінці, просто для будь-якого майбутнього читача.
Кейр Неллер

4
Тож якщо я встановлю нову версію Java, і JAVA_HOME вказує на новий каталог, чи не виникне проблем із сертифікатом?
Кирило Юнусов

1
@Murphy: Це може допомогти вам stackoverflow.com/questions/5251323/…
kosa

4
я думаю, це місце довіреного магазину, а не ключове місце магазину.
користувач2001850

35

Розташування клавіатури

Кожна команда keytool має -keystoreможливість вказати ім'я та місце розташування стійкого файлу зберігання ключів для зберігання ключів, керованого keytool. За замовчуванням зберігання клавіш зберігається у файлі, названому .keystoreв домашній директорії користувача, що визначається властивістю системи "user.home". З огляду на ім’я користувача uName, значення властивості "user.home" за замовчуванням до

C:\Users\uName on Windows 7 systems
C:\Winnt\Profiles\uName on multi-user Windows NT systems
C:\Windows\Profiles\uName on multi-user Windows 95 systems
C:\Windows on single-user Windows 95 systems

Таким чином, якщо ім'я користувача "cathy", "user.home" за замовчуванням до

C:\Users\cathy on Windows 7 systems
C:\Winnt\Profiles\cathy on multi-user Windows NT systems
C:\Windows\Profiles\cathy on multi-user Windows 95 systems

http://docs.oracle.com/javase/1.5/docs/tooldocs/windows/keytool.html


Я шукав цей ~/.keystoreфайл таємниці ! Якщо я вимкнув -keystoreпараметр, я не міг визначити, на яке keytoolнацілення клавіша зберігання за замовчуванням . Я продовжував шукати іншихcacerts десь на машині. Я не очікував, що keytool генерується ~/.keystoreу домашньому каталозі, а також для того, щоб його іменовано .keystoreзамість cacerts. Ви заповнили бланк, який повинні документувати люди Java! Дякую!
Джордж Пантазес

26

Mac OS X 10.12 з Java 1.8:

$ JAVA_HOME / jre / lib / безпека

cd $JAVA_HOME

/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home

Звідти це:

./jre/lib/security

У мене там зберігається брелок для ключів.

Щоб вказати це як параметр VM:

-Djavax.net.ssl.trustStore=/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre/lib/security/cacerts -Djavax.net.ssl.trustStorePassword=changeit

Я не кажу, що це правильний спосіб (чому ява не знає шукати всередині JAVA_HOME?), Але це те, що я повинен був зробити, щоб він працював.


16

Ви можете знайти його у своєму каталозі "Домашня сторінка":

У Windows 7:

C:\Users\<YOUR_ACCOUNT>\.keystore

У Linux (Ubuntu):

/home/<YOUR_ACCOUNT>/.keystore

4
У мене немає цього каталогу на Windows
simgineer

1
Я зробив -keygen, не вказуючи зберігання ключів, очікуючи, що він створить його в поточному каталозі, але він створив його в моєму домі, як ви сказали. ~ / .keystore Не вдалося знайти його протягом століть! :-) Дякую.
Eurospoofer

дозвольте додати, що під cygwin використовується шлях Windows, оскільки властивість java user.homeдорівнює $HOMEDRIVE$HOMEPATHвстановленому windows, а не $HOMEвстановленому cygwin де HOMEDRIVE=C:таHOMEPATH=\Users\[YOUR ACCOUNT]
user1708042

13

Це працює для мене:

#! / бін / баш

CACERTS = $ ( readlink - e $ ( dirname $ ( readlink - e $ ( який keytool ))) /../ lib / security / cacerts )

якщо keytool - список - зберігання ключів $ CACERTS - storepass changeit > / dev / null ; тоді  
    echo $ CACERTS
else 
    echo "Неможливо знайти файл cacerts." > & 2 
    вихід 1 fi 

Тільки для Linux. Мій Solaris не має посилання для читання. Врешті-решт я використав цей Perl-скрипт:

#! / usr / bin / env perl використовувати суворо ; використовувати попередження ; використовувати Cwd qw ( realpath ); 
$ _ = realpath (( grep {- x && - f } map { "$ _ / keytool" } split ( ':' , $ ENV { PATH })) [ 0 ]);


  
die "Неможливо знайти keytool", якщо не визначено $ _ ; мій $ keytool = $ _ ; друк  

 "Використання" $ keytool ". \ N" ; 
s / keytool $ / /;
$ _ = realpath ($ _. '../ lib / security / cacerts ');
die "Не можу знайти какадери", якщо тільки -f $ _;
мої $ cacerts = $ _;
друк "Імпорт у" $ cacerts ". \ n";
`$ keytool -list -keystore" $ cacerts "- зберігання змін";
die "Неможливо прочитати контейнер з ключами", якщо не є $? == 0;
вихід, якщо $ ARGV [0] eq ' - d ';
foreach (@ARGV) {
    мій $ cert = $ _;
    s /\. evidence^.Sense+$//;
    мій $ псевдонім = $ _;
    друкувати "Імпорт" $ cert "як" $ псевдонім ". \ n";
    `keytool -importcert -file" $ cert "-alias" $ alias "-keystore" $ cacerts "-storepass changeit`;
    попередити "Не можна імпортувати сертифікат: $?" хіба що $? == 0;
}

6

Як згадував DimtryB, за замовчуванням зберігання клавіш знаходиться під каталогом користувачів. Але якщо ви намагаєтесь оновити cacertsфайл, щоб JVM міг вибрати ключі, тоді вам доведеться оновити cacertsфайл у розділі jre/lib/security. Ви також можете переглянути клавіші, виконавши команду, keytool -list -keystore cacertsщоб побачити, чи доданий ваш сертифікат.


Приємно знати, що команда keytool lib/securityавтоматично додає правильний шлях, якщо вказується лише відносна назва.
припинення

1
Але це не спрацює -importcert. Команда list показує системні сертифікати, але команда import створює новий файл у поточному каталозі.
припинення

1
updatedb; locate cacertsдопомагає дізнатися, де знаходяться місця встановлення файлів електронних служб.
sjas

5

У Debian, використовуючи Openjdk версію "1.8.0_212", я знайшов тут касети:

 /etc/ssl/certs/java/cacerts

Звичайно, було б зручно, якби була стандартна команда, яка роздрукувала б цей шлях.


1

Для мене, використовуючи офіційне зображення OpenJDK 12 Docker , розташування сховища Java було таким:

/usr/java/openjdk-12/lib/security/cacerts

Це довіра, а не брелок.
Маркіз Лорн

1
По-перше: Якщо ви уважно читаєте запитання (і власний коментар), це звучить більше як Truststore, куди слід імпортувати сертифікат. По-друге, різниця між Truststore і Keystore є досить дезорієнтуючим - і обидва використовують термін "Keystore" btw, оскільки вони використовують формат і те, і інше. По-третє: Якщо ви подивитесь на команду імпорту, keytool -import -file example.crt -alias exampleCA -keystore truststore.jksви також використовуєте параметр -keystore... досить незрозумілий IMHO. І останнє, але не менш важливе: я шукав саме цю проблему - і знайшов таке питання. Можливо, інші експерують те саме.
jonashackt

Крім того, всі інші відповіді також стосуються так званого "Довіри", який JDK використовує для перевірки. Тож ви також спростували всі інші відповіді? Я вже отримав задоволення, тому вже є хтось, на що моя відповідь допомогла.
jonashackt

0

Ми зіткнулися з цією проблемою на Tomcat, який працює з каталогу jre, який був видалений (майже повністю) після автоматичного оновлення jre, так що запущений jre більше не міг знайти jre ... / lib / security / cacerts, оскільки його більше не існувало.

Перезапуск Tomcat (після зміни конфігурації для запуску з іншого jre-місця) вирішив проблему.


0

На додаток до всіх відповідей вище:

Якщо оновлення файлу кесерів у каталозі JRE не допомагає, спробуйте оновити його в JDK.

C: \ програмні файли \ Java \ jdk1.8.0_192 \ jre \ lib \ безпека

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.