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

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

44 голосов
/ 05 декабря 2011

Я пытаюсь подписать код JAR-файл и использую JDK 1.7u1. Мы получили сертификат подписи кода GoDaddy, и я следовал инструкциям (подход 1) здесь: http://help.godaddy.com/article/4780

JAR подписывает нормально, однако всякий раз, когда я пытаюсь выполнить команду: jarsigner -verify на моем подписанном JAR с использованием JDK 1.7u1 я получаю следующий вывод: 

s        180 Mon Dec 05 10:24:32 EST 2011 META-INF/MANIFEST.MF

      [entry was signed on 12/5/11 10:24 AM]
      X.509, CN=Removed Company Name, O=Removed Company Name, L=Removed City, ST=Removed State, C=US
      [certificate is valid from 12/2/11 4:30 PM to 12/2/13 4:30 PM]
      X.509, SERIALNUMBER=00000000, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
      [certificate is valid from 11/15/06 8:54 PM to 11/15/26 8:54 PM]
      X.509, OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
      [certificate is valid from 6/29/04 1:06 PM to 6/29/34 1:06 PM]
      [CertPath not validated: null]

         342 Mon Dec 05 10:24:34 EST 2011 META-INF/JAVACSC.SF
        6180 Mon Dec 05 10:24:34 EST 2011 META-INF/JAVACSC.RSA
           0 Mon Dec 05 10:24:30 EST 2011 META-INF/
sm      2161 Wed Nov 30 10:23:20 EST 2011 C:/Users/Seth/Desktop/JAR/RunAppSF.class

      [entry was signed on 12/5/11 10:24 AM]
      X.509, CN=Removed Company Name, O=Removed Company Name, L=Removed City, ST=Removed State, C=US
      [certificate is valid from 12/2/11 4:30 PM to 12/2/13 4:30 PM]
      X.509, SERIALNUMBER=00000000, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
      [certificate is valid from 11/15/06 8:54 PM to 11/15/26 8:54 PM]
      X.509, OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
      [certificate is valid from 6/29/04 1:06 PM to 6/29/34 1:06 PM]
      [CertPath not validated: null]


  s = signature was verified 
  m = entry is listed in manifest
  k = at least one certificate was found in keystore
  i = at least one certificate was found in identity scope

jar verified.

Warning: 
This jar contains entries whose certificate chain is not validated.

Я также попробовал команду jarsigner -verify, используя тот же JAR, что и выше, в JDK 1.6u26 и 1.6u14, и он вернулся как нормальный. (Вывод ниже от 1.6u26). 

         180 Mon Dec 05 10:24:32 EST 2011 META-INF/MANIFEST.MF
         342 Mon Dec 05 10:24:34 EST 2011 META-INF/JAVACSC.SF
        6180 Mon Dec 05 10:24:34 EST 2011 META-INF/JAVACSC.RSA
           0 Mon Dec 05 10:24:30 EST 2011 META-INF/
sm      2161 Wed Nov 30 10:23:20 EST 2011 C:/Users/Seth/Desktop/JAR/RunAppSF.class

      [entry was signed on 12/5/11 10:24 AM]
      X.509, CN=Removed Company Name, O=Removed Company Name, L=Removed City, ST=Removed State, C=US
      [certificate is valid from 12/2/11 4:30 PM to 12/2/13 4:30 PM]
      X.509, SERIALNUMBER=00000000, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
      [certificate is valid from 11/15/06 8:54 PM to 11/15/26 8:54 PM]
      [KeyUsage extension does not support code signing]
      X.509, OU=Go Daddy Class 2 Certification Authority, O="The Go Daddy Group, Inc.", C=US
      [certificate is valid from 6/29/04 1:06 PM to 6/29/34 1:06 PM]


  s = signature was verified 
  m = entry is listed in manifest
  k = at least one certificate was found in keystore
  i = at least one certificate was found in identity scope

jar verified.

Я пропустил дополнительный шаг, который мне нужно сделать, чтобы правильно подписать JAR для JDK 1.7?

Ответы [ 8 ]

77 голосов
/ 12 мая 2012

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

Чтобы устранить проблему, выполните: 

jarsigner -verify -keystore xxxx.jks mysignedjar.jar
49 голосов
/ 16 декабря 2011

Вы не ничего не упустили, и вы определенно не наедине с этой проблемой.После почти 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 без какого-либо предупреждения, которое, как я полагаю, является тем, чего вы ожидаете.

18 голосов
/ 12 сентября 2013

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

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

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

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

5 голосов
/ 18 марта 2015

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

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

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

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

Поскольку нет никакого способа явно сказать 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 или Root, если он указан командой keytool -list, но с -v (подробный) он раскрывает глубину цепи и свои сертификаты: 

~/$ 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 проверяемым также для конечного пользователя браузера.

2 голосов
/ 15 января 2015

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

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

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

2 голосов
/ 15 августа 2013

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

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

0 голосов
/ 09 июля 2014

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

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

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

0 голосов
/ 17 октября 2013

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

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

Проблема:

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

Решение:

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

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

...