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

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

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

Ответы

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

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