Java SecurityException: le informazioni sul firmatario non corrispondono

Ho ricompilato le mie classi come al solito e improvvisamente ho ricevuto il seguente messaggio di errore. Perché? Come posso ripararlo?

java.lang.SecurityException: class "Chinese_English_Dictionary"'s signer information does not match signer information of other classs in the same package at java.lang.ClassLoader.checkCerts(ClassLoader.java:776) 

Questo accade quando le classi appartenenti allo stesso pacchetto vengono caricate da diversi file JAR, e quei file JAR hanno firme firmate con certificati diversi – o, forse più spesso, almeno una è firmata e una o più altre non lo sono (che include le classi caricate dalle directory dato che quelli AFAIK non possono essere firmati).

Quindi assicuratevi che tutti i JAR (o almeno quelli che contengono classi dagli stessi pacchetti) siano firmati usando lo stesso certificato, o rimuovete le firme dal manifest dei file JAR con pacchetti sovrapposti.

Un modo semplice per aggirarlo è semplicemente provare a cambiare l’ordine dei file jar importati che possono essere fatti da (Eclipse). Fai clic con il pulsante destro del mouse sul pacchetto -> Percorso di creazione -> Configura percorso di creazione -> Riferimenti e librerie -> Ordina ed esporta. Prova a cambiare l’ordine dei jar che contengono i file delle firme.

A. Se usi Maven, un modo utile per eseguire il debug di un conflitto su jar è:

 mvn dependency:tree 

Ad esempio, per un’eccezione:

 java.lang.SecurityException: class "javax.servlet.HttpConstraintElement"'s signer information does not match signer information of other classs in the same package 

noi facciamo:

 mvn dependency:tree|grep servlet 

La sua produzione:

 [INFO] +- javax.servlet:servlet-api:jar:2.5:compile [INFO] +- javax.servlet:jstl:jar:1.2:compile [INFO] | +- org.eclipse.jetty.orbit:javax.servlet.jsp:jar:2.2.0.v201112011158:compile [INFO] | +- org.eclipse.jetty.orbit:javax.servlet.jsp.jstl:jar:1.2.0.v201105211821:compile [INFO] | +- org.eclipse.jetty.orbit:javax.servlet:jar:3.0.0.v201112011016:compile [INFO] +- org.eclipse.jetty:jetty-servlet:jar:9.0.0.RC2:compile 

mostra clashing servlet-api 2.5 e javax.servlet 3.0.0.x.

B. Altri suggerimenti utili (come eseguire il debug dell’eccezione di sicurezza e come escludere i servizi di assistenza) sono alla domanda al momento in cui le informazioni del firmatario non corrispondono .

Nel mio caso, avevo duplicato la versione JAR di BouncyCastle nel mio percorso della libreria: S

Ciò può verificarsi con i proxy cglib-instrumented poiché CGLIB utilizza le proprie informazioni sul firmatario anziché le informazioni sul firmatario della class di destinazione dell’applicazione.

Ho avuto un’eccezione simile:

 java.lang.SecurityException: class "org.hamcrest.Matchers"'s signer information does not match signer information of other classs in the same package 

Il problema principale era che includevo la libreria di Hamcrest due volte. Una volta usando il file pom Maven. E ho anche aggiunto la libreria JUnit 4 (che contiene anche una libreria di Hamcrest) al percorso di costruzione del progetto. Ho semplicemente dovuto rimuovere JUnit dal percorso di costruzione e tutto andava bene.

  1. Dopo il segno, accedi: dist \ lib
  2. Trova extra .jar
  3. Usando Winrar, estrai per una cartella (estrai in “nome cartella”) opzione
  4. Accesso: META-INF / MANIFEST.MF
  5. Elimina ogni firma in questo modo:

Nome: net / sf / jasperreports / engine / util / xml / JaxenXPathExecuterFactory.c lass SHA-256-Digest: q3B5wW + hLX / + lP2 + L0 / 6wRVXRHq1mISBo1dkixT6Vxc =

  1. Salva il file
  2. Zip di nuovo
  3. Renaime est. Indietro
  4. Già

Se lo stai eseguendo in Eclipse, controlla i vasi di tutti i progetti aggiunti al percorso di generazione; oppure fai control-shift-T e cerca più jar che corrispondono allo stesso spazio dei nomi. Quindi rimuovere i jar ridondanti o obsoleti dal percorso di generazione del progetto.

Nel mio caso si trattava di un conflitto di nomi di pacchetti. Il progetto corrente e la libreria referenziata firmata avevano un pacchetto in common package.foo.utils . Ho appena cambiato l’attuale nome del pacchetto sobject a errori del progetto in qualcos’altro.

Ciò si verifica anche se includi due volte un file con nomi diversi o da posizioni diverse, specialmente se si tratta di due versioni diverse dello stesso file.

Potrei aggiustarlo

Causa principale: questo è un problema comune quando si utilizza l’implementazione Sun JAXB con i jar firmati. In sostanza, l’implementazione di JAXB sta tentando di evitare la riflessione generando una class per accedere direttamente alle proprietà senza utilizzare la reflection. Sfortunatamente, genera questa nuova class nello stesso pacchetto della class a cui si accede da cui proviene questo errore.

Soluzione: aggiungere la seguente proprietà di sistema per disabilitare le ottimizzazioni JAXB che non sono compatibili con i contenitori firmati: -Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize = true

Rif: https://access.redhat.com/site/solutions/42149

In base alla risposta di @Mohit Phougat, se stai eseguendo una Groovy con annotazioni @Grab, puoi provare a riordinare tali annotazioni.

Un thread un po ‘troppo vecchio ma dato che sono rimasto bloccato per un po’ di tempo su questo, ecco la correzione (spero che aiuti qualcuno)

Il mio scenario:

Il nome del pacchetto è: com.abc.def. Ci sono 2 file jar che contengono classi da questo pacchetto, diciamo jar1 e jar2, cioè alcune classi sono presenti in jar1 e altre in jar2. Questi file jar sono firmati utilizzando lo stesso keystore ma in momentjs diversi della build (ovvero separatamente). Ciò sembra comportare una firma diversa per i file in jar1 e jar2.

Ho messo tutti i file in jar1 e li ho creati (e firmati) tutti insieme. Il problema va via.

PS: i nomi dei pacchetti e i nomi dei file jar sono solo degli esempi

Se hai aggiunto tutti i vasi da bouncycastle.org (nel mio caso da crypto-159.zip), rimuovi solo quelli per i JDK che non si applicano a te. Ci sono ridondanze. Probabilmente hai solo bisogno dei vasi “jdk15on”.