Pergunta

Eu tenho trabalhado com início web para um par de anos e tem experiência com a assinatura dos frascos e quais não. Estou levando minha primeira tentativa de implantação de um aplicativo RCP com início web e embora eu tenha de fato assinado todos os frascos com o mesmo certificado Recebo este erro: 'recursos jar em jnlp não são assinados pelo mesmo certificado'

Tem mais alguém deparei com isso? Se assim for, todas as idéias sobre como corrigir?

Foi útil?

Solução

Quando eu tive problemas semelhantes depois de verificar os frascos Descobriu-se que alguns terceiro frasco partido foi assinado por outra pessoa.

Você deve criar um arquivo jnlp separado para os frascos assinados pelo outro certificado e ler este jnlp de seu arquivo jnlp:

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

Aqui ou aqui pode encontrar um exemplo.

Outras dicas

Esta pode ser uma entrada de manifesto obsoleto a partir de um frasco já assinado que você usar como uma biblioteca. Eu encontrei este problema com JOGL via webstart. Tente isto:

Descompacte todos os frascos, purgar todo o META-INF diretórios, frasco e assiná-las novamente.

Descobri que JNLP / Webstart não gosta várias assinaturas / assinatura via jarsigner.exe para um determinado JAR. Se um JAR, como BouncyCastle (que vem presigned) é assinado novamente com o certificado de sua empresa, leads de inspeção visual me a acreditar que o novo certificado e as assinaturas são executados corretamente no JAR. mas que JNLP pode ser ler apenas a primeira assinatura (alfabética?) no META-INF, e queixando-se, assim, que não coincide com seus outros JARs (que têm apenas um, Corporate, assinatura de cada JAR).

Eu tive exatamente a mesma experiência como descrita por Mateus com os JARs BouncyCastle presigned. No entanto, descobri que JRE versão 1.6.0_14 e mais tarde vai aceitar de bom grado frascos com várias assinaturas (como seria de esperar). Por isso, eu não preciso usar o JNLP 'mecanismo de extensão componente' descrito acima.

PS Não encontrou quaisquer referências óbvias a essa correção nos 1.6.0_14 notas de lançamento. No entanto, tenho verificado que vários assinado JAR obras em todas as versões posteriores (pelo menos 14 - 17 + 24).

No meu projeto, o que aconteceu é que existem alguns casos na piscina do balanceador de carga, existem alguns casos com versão antiga do código e alguns com nova versão. Assim, existem certificados não assinados pelo mesmo certificado ...

O número de série seguintes listas de script do certificado RSA em cada frasco in / algum diretório / lib e ajuda para encontrar frascos que são assinados pelo certificado errado:

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
Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top