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

Question

Я работаю с веб-стартом уже пару лет, и у меня есть опыт подписания банок, а что нет. Я делаю свою первую попытку развертывания приложения RCP с веб-запуском, и хотя я фактически подписал все jar-файлы одним и тем же сертификатом, я продолжаю получать эту ошибку: «ресурсы jar в jnlp не подписаны одним и тем же сертификатом»

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

Следующий скрипт перечисляет серийный номер сертификата 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

Answer 7

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