Я работаю с веб-стартером уже пару лет и имею опыт работы с подписью банками, а что нет. Я делаю свою первую попытку развертывания приложения RCP с веб-запуском, и хотя я фактически подписал все банки с тем же сертификатом, я продолжаю получать эту ошибку: "jar-ресурсы в jnlp не подписаны одним и тем же сертификатом"
Кто-нибудь еще сталкивался с этим? Если да, то какие-либо идеи о том, как исправить?
Когда у меня возникли подобные проблемы после проверки банок, выяснилось, что некоторые сторонние банки были подписаны кем-то другим.
Вам следует создать отдельный файл jnlp для банок, подписанных другим сертификатом, и прочитать этот jnlp из файла jnlp:
<resources>
...
<extension name="other" href="other.jnlp"/>
</resources>
Это может быть устаревшая запись манифеста из уже подписанной банки, которую вы используете в качестве библиотеки. Я столкнулся с этой проблемой с помощью jogl через webstart. Попробуйте следующее:
Распакуйте все банки, очистите все каталоги META-INF, банку и подпишите их снова.
Я обнаружил, что JNLP/Webstart не любит несколько подписей/подписей через jarsigner.exe для данного JAR. Если JAR, такой как BouncyCastle (который присваивается), снова подписывается с сертификатом вашей компании, визуальный осмотр заставляет меня думать, что новый сертификат и подписи выполняются должным образом в JAR. но что JNLP может читать только первую (по алфавиту?) подпись в META-INF и тем самым жалуется, что она не соответствует вашим другим JAR (которые имеют только одну, корпоративную подпись в каждом JAR).
См. объяснение для одного из часто задаваемых вопросов: Как использовать несколько файлов JAR, подписанных разными сертификатами?
Правильное решение.
У меня был тот же опыт, что описал Мэтью с назначенными JARs BouncyCastle. Тем не менее, я обнаружил, что JRE версии 1.6.0_14 и позже с радостью будут принимать JAR с несколькими сигнатурами (как и следовало ожидать). Следовательно, мне не нужно было использовать механизм расширения компонентов JNLP, описанный выше.
PS Не нашел явных ссылок на это исправление в примечаниях к выпуску 1.6.0_14. Тем не менее, я подтвердил, что несколько подписанных JAR работают во всех более поздних версиях (не менее 14 - 17 + 24).
В моем проекте произошло то, что в пуле балансировки нагрузки есть несколько экземпляров, есть несколько экземпляров со старой версией кода, а некоторые с новой версией. Таким образом, есть сертификаты, не подписанные одним и тем же сертификатом...
Следующий скрипт перечисляет серийный номер сертификата 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