ресурсы jar в jnlp не подписаны одним и тем же сертификатом

StackOverflow https://stackoverflow.com/questions/430755

  •  08-07-2019
  •  | 
  •  

Вопрос

Я работаю с web start уже пару лет, и у меня есть опыт подписывания jars и того, что нет.Я предпринимаю свою первую попытку развертывания приложения RCP с помощью web start, и хотя я фактически подписал все банки одним и тем же сертификатом, я продолжаю получать эту ошибку:"ресурсы jar в jnlp не подписаны одним и тем же сертификатом"

Кто-нибудь еще сталкивался с этим?Если да, то есть какие-нибудь идеи о том, как это исправить?

Это было полезно?

Решение

Когда у меня возникли подобные проблемы после проверки банок, оказалось, что кто-то другой подписал банку третьей стороны.

Вы должны создать отдельный файл jnlp для jar-файлов, подписанных другим сертификатом, и прочитать этот jnlp из вашего файла jnlp: 

<resources>
  ...
  <extension name="other" href="other.jnlp"/>
</resources>

здесь или здесь вы можете найти пример.

Другие советы

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

Разархивируйте все фляги, очистите все каталоги META-INF, заархивируйте и подпишите их снова.

Я обнаружил, что JNLP / Webstart не любит множественные подписи / подписи через jarsigner.exe для данного JAR. Если JAR, такой как BouncyCastle (который поставляется заранее), снова подписан сертификатом вашей компании, визуальный осмотр заставляет меня поверить, что новый сертификат и подписи в JAR выполняются правильно. но JNLP может читать только первую (алфавитную?) сигнатуру в META-INF и, таким образом, жаловаться, что она не соответствует вашим другим JAR-файлам (у которых есть только одна корпоративная подпись на каждом JAR).

У меня был точно такой же опыт, как описано Мэтью, с баночками BouncyCastle, подписанными под заказ.Однако я обнаружил, что JRE версии 1.6.0_14 и более поздних версий с радостью примет JAR с несколькими подписями (как я и ожидал).Следовательно, мне не нужно было использовать "механизм расширения компонента" JNLP, описанный выше.

PS Не нашел никаких очевидных ссылок на это исправление в примечаниях к выпуску 1.6.0_14.Однако я проверил, что несколько подписанных JAR работают во всех более поздних версиях (по крайней мере 14 - 17 + 24).

См. объяснение одного из часто задаваемых вопросов: Как использовать несколько файлов JAR, подписанных разными сертификатами?

Правильное решение.

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

Следующий скрипт перечисляет серийный номер сертификата RSA в каждом jar-каталоге в каталоге / some / lib и помогает найти jar-файлы, подписанные неправильным сертификатом: 

for f in $( find /some/lib -type f -name '*.jar' )
do 
   serial=$( unzip -p $f 'META-INF/*.RSA' | 
             openssl pkcs7 -inform der -print -noout |
             grep --max-count=1 serialNumber | cut -d: -f2- | tr -d ' ' )
   printf "%40s: %s\n" "$serial" "$f"
done
Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top