Jarsigner: эта банка содержит записи, цепочка сертификатов которых не проверена

Ответ 1

У вас не отсутствует что-либо, и вы определенно не самостоятельно с этой проблемой. После почти 12 часов борьбы я понял, что корень проблемы заключается в смешении двоичных файлов из JDK 1.7 со старой версией Java, такой как JRE-1.6. Точнее, keytool поставляется с JRE, а JDK поставляется с keytool и jarsigner.

Итак, чтобы решить эту проблему, я полностью удалил JDK-1.7 из своей системы и установил JDK-1.6 Update 30. Теперь, если бы я сделал jarsigner -verify -verbose -certs blah.jar, он произвел jar verified без какого-либо предупреждения, которое, я считаю, является тем, что вы ожидаете.

Ответ 2

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

Чтобы устранить проблему, выполните следующие действия:

jarsigner -verify -keystore xxxx.jks mysignedjar.jar

Ответ 3

Это просто предупреждение, которое вы можете игнорировать.

Если вы действительно не хотите игнорировать его, сообщите jarsigner, где ваше хранилище ключей, когда вы проверяете.

jarsigner -verbose -verify -keystore ${KEYSTORE_PATH} ${YOUR_JAR_FILE}

Это просто новая функция в JDK 7.

Ответ 4

У меня была схожая проблема с "DigiCert SHA2 Assured ID Code Signing CA". Все версии oracle java, а также OpenJDK вели себя одинаково. Поддержка Digicert перенаправила меня на эту страницу, но ничто из этого не помогло мне в процессе проверки.

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

Основная проблема, похоже, является ошибкой в ​​keytool при работе с сертификатами, использующими SHA2 вместо SHA1, потому что тот же список шагов, примененных к сертификатам SHA1, всегда работает и никогда не работал для SHA2 для меня. Мне кажется, что keytool не способен обнаруживать "цепочки" сертификатов, импортированных в jks, и поэтому jarsigner не вставляет правильную цепочку сертификатов в подписанную банку, есть только окончательный сертификат, хранящийся в META-INF/myalias. RSA файл (проверяемый openssl pkcs7 -in myalias.RSA -print_certs -inform DER -out certs.crt).

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

Поскольку явным образом не могу явно указать, какие сертификаты должны быть в цепочке, я решил создать цепочку с помощью openssl и импортировать ее следующим образом:

cat TrustedRoot.pem DigiCertCA2.pem my.crt  >chain
openssl pkcs12 -nodes -export -in my.crt  -inkey my.key -out tmp.p12 -name myalias -certfile chain
keytool -importkeystore -destkeystore mykeystore.jks -srckeystore tmp.p12 -srcstoretype PKCS12

После этого mykeystore.jks, похоже, содержит только мой сертификат, а не DigiCertCA2 или Root, когда он указан командой keytool -list, но с -v (verbose) раскрывает глубину цепи и ее сертификаты:

~/$ keytool  --list --keystore mykeystore.jks  -v|grep -e chain -e Certificate\\[
Enter keystore password:  123456
Certificate chain length: 3
Certificate[1]:
Certificate[2]:
Certificate[3]:

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

Ответ 5

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

Заключение: нет необходимости переходить на Java 1.6, просто используйте ту же самую версию jarsigner для подписания и проверки.

Ответ 6

Это механизм безопасности в JDK 7+. Это выводит предупреждение при подписании баннеров без отметки времени, которая может быть передана с флагом -tsa. Если в банке нет метки времени, она перестанет работать после даты ее действия.

Если вы создаете цель для Android, это предупреждение будет всегда печататься, если вы используете JDK более новый, чем 1.7.0_51. Android обычно рекомендует пропустить 30-летнюю гарантию, поэтому это предупреждение может быть проигнорировано на 100%, если вы не планируете бизнес-план, чтобы пользователи могли использовать тот же .apk в 2046 году.

Вот билет для этой функции, цель - поощрять временную привязку, которая, как я считаю, будет эффективной. http://bugs.java.com/view_bug.do?bug_id=8023338.

Ответ 7

Если ваши сертификаты принадлежат Entrust, убедитесь, что вы используете новый корневой сертификат.

http://www.entrust.net/knowledge-base/technote.cfm?tn=7875

Проблема:

Появляется сообщение об ошибке, в котором указывается ваш SLL-сертификат проверка не выполнена из-за отсутствия основного поля ограничений.

Решение:

В 2009 году Entrust переиздал 2048-битный корневой сертификат для включения поле "Основные ограничения" (cn = Центр сертификации Entrust.net(2048), действительный до 7/24/2029). Entrust прекратил выталкивать исходный 2048-битный корень через корневые обновления в Windows и Java (начиная с версии 1.6 обновления 22). Обновленный корневой сертификат содержащие основные ограничения, можно найти здесь:

https://www.entrust.net/downloads/binary/entrust_2048_ca.cer

Ответ 8

Когда вы создаете/экспортируете свой сертификат на p12 (используется jarsigner), убедитесь, что вы выбрали следующее (например, если вы экспортируете с помощью мастера Internet Explorer), вам нужно будет выбрать следующее в мастере экспорта.

"Экспорт секретного ключа" "Включите все сертификаты в путь сертификации, если это возможно" "Экспортировать все расширенные свойства" отмечен в опции .PFX или PKCS # 12.

Если вы правильно создаете p12, то jarsign не требует особых усилий.