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

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

чтобы исправить проблему, сделайте:

jarsigner -verify -keystore xxxx.jks mysignedjar.jar

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

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

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

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

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

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

основная проблема, похоже, ошибка в keytool при работе с сертификатами, использующими SHA2 вместо SHA1, потому что тот же список шагов, примененных к сертификатам SHA1, всегда работает и никогда не работал для SHA2 для меня. Мне кажется, что keytool не способен обнаруживать "цепочку" сертификатов, импортированных в jks, и, таким образом, jarsigner не вставляет правильную цепочку сертификатов в подписанную банку, есть только окончательный сертификат, хранящийся в META-INF/myalias.ОГА файл вместо (проверяемые в OpenSSL pkcs7 в -в Алиас.RSA-print_certs -информ-дер -вне корпуса.ЭЛТ.)

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

поскольку нет возможности явно сказать keytool, какие сертификаты будут в цепочке, я решил построить цепочку с помощью 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 или корень, когда он указан командой 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 должен подписать банку правильно, т. е. внедрить правильную цепочку сертификатов и сделать jar проверяемым также для конечного пользователя браузера.

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

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

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

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

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

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

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

:

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

устранение:

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

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

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

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

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