Java Security: signer Informationen nicht übereinstimmt

StackOverflow https://stackoverflow.com/questions/2877262

Frage

neu kompilierte ich meine Klassen wie gewohnt, und bekam plötzlich die folgende Fehlermeldung. Warum? Wie kann ich das Problem beheben? 

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

Lösung

Dies geschieht, wenn Klassen zu demselben Paket gehören, aus verschiedenen JAR-Dateien geladen werden, und die JAR-Dateien haben Signaturen mit unterschiedlichen Zertifikaten signiert - oder vielleicht oft mehr, zumindest ein unterzeichnet und einer oder mehr andere nicht (die geladenen Klassen von Verzeichnissen umfasst da jene AFAIK nicht unterzeichnet werden).

Also entweder sicherstellen, dass alle JAR-Dateien (oder zumindest solche, die Klassen aus den gleichen Paketen enthalten) werden mit demselben Zertifikat signiert, oder entfernen Sie die Signaturen aus dem Manifest der JAR-Dateien mit Paketen überlappen.

Andere Tipps

Ein einfacher Weg, um es nur versuchen, die Reihenfolge der importierten JAR-Dateien zu ändern, die aus (Eclipse) getan werden können. Rechtsklick auf Ihrem Paket -> Build Path -> Konfigurieren Build-Pfad -> Referenzen und Bibliotheken -> Auftrags und Export. Versuchen Sie, die Reihenfolge der Gläser zu ändern, die enthalten Signaturdateien.

A. Wenn Sie Maven, eine nützliche Methode zu debuggen Klirren Gläser ist: 

mvn dependency:tree

Zum Beispiel für eine Ausnahme: 

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

wir tun: 

mvn dependency:tree|grep servlet

Sein Ausgang: 

[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

zeigt clashing Servlet-API 2.5 und javax.servlet 3.0.0.x.

B. Weitere nützliche Hinweise (wie die Sicherheitsausnahme zu debuggen und wie maven deps auszuschließen) sind bei der Frage an Signer Informationen nicht übereinstimmt .

In meinem Fall hatte ich JAR-Version von BouncyCastle in meiner Bibliothek Pfad dupliziert: S

Ich hatte eine ähnliche Ausnahme: 

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

Das eigentliche Problem war, dass ich zweimal die hamcrest Bibliothek enthalten. Sobald Datei Maven pom verwenden. Und ich auch die JUnit 4-Bibliothek (die auch enthält eine hamcrest Bibliothek) an das Build-Pfad des Projektes hinzugefügt. Ich hatte einfach JUnit aus dem Build-Pfad zu entfernen und alles war in Ordnung.

Dies kann mit den cglib-instrumentierten Proxies auftreten, weil CGLIB seine eigenen Unterzeichner Informationen verwendet, anstatt die Unterzeichner Informationen der Anwendung Zielklasse.

  1. Nach der Anmeldung, Zugang: dist \ lib
  2. Suchen zusätzliche .jar
  3. Verwenden von Winrar, Sie extrahieren für einen Ordner (Auszug auf "Ordnername") Option
  4. Zugang: META-INF / MANIFEST.MF
  5. Löschen jede Signatur wie folgt aus:

Name: net / sf / Jasper / Motor / util / xml / JaxenXPathExecuterFactory.c Mädel SHA-256-Digest: q3B5wW + HLX / + LP2 + L0 / 6wRVXRHq1mISBo1dkixT6Vxc =

  1. Speichern Sie die Datei
  2. Zip wieder
  3. Renaime ext .jar zurück
  4. Bereits

Wenn Sie es in Eclipse ausführen, überprüfen Sie die Gläser aller Projekte auf den Build-Pfad hinzugefügt; oder steuere-shift-T und Scan für mehrere Gefäße den gleichen Namensraum entspricht. Dann entfernen Sie redundante oder veraltete Gläser aus dem Build-Pfad des Projekts.

In meinem Fall war es ein Paketname Konflikt. Aktuelles Projekt und unterzeichnet referenzierten Bibliothek hatte ein Paket gemeinsam package.foo.utils. Gerade die aktuellen Projekt fehleranfällige Paketnamen etwas anderes geändert.

Ein bisschen zu alten Thread aber da ich schon seit geraumer Zeit auf diese stecken geblieben war, hier ist das Update (hoffe, es hilft jemand)

Ihr Szenario:

Der Paketname ist: com.abc.def. Es gibt zwei JAR-Dateien, die Klassen aus diesem Paket etwa jar1 enthalten und jar2 das heißt einige Klassen vorhanden sind, in jar1 und andere in jar2. Diese JAR-Dateien signiert sind die gleichen Schlüsselspeicher verwenden, aber zu verschiedenen Zeiten in der Build (das heißt separat). Das scheint in andere Signatur für die Dateien in jar1 und jar2 führen.

Ich habe alle Dateien in jar1 und gebaut (und unterschrieben) sie alle zusammen. Das Problem geht weg.

PS: Die Paketnamen und jar Dateinamen sind nur Beispiele

Dies geschieht auch, wenn Sie eine Datei mit verschiedenen Namen oder von verschiedenen Standorten zweimal enthalten, vor allem, wenn es sich um zwei verschiedene Versionen der gleichen Datei.

Ich konnte es beheben.

Root Cause: Dies ist ein häufiges Problem, wenn die Sun JAXB Umsetzung mit signierten Gläser verwenden. Im Wesentlichen wird die JAXB Umsetzung versucht Reflexion zu vermeiden, indem eine Klasse zu erzeugen, um direkt die Eigenschaften zugreifen, ohne Reflexion verwendet wird. Leider erzeugt es diese neue Klasse im selben Paket wie die Klasse zugegriffen wird, das ist, wo dieser Fehler kommt.

Auflösung: Fügen Sie die folgende Systemeigenschaft, um die JAXB Optimierungen zu deaktivieren, die mit signierten Gläser nicht kompatibel sind: -Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize = true

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

Basierend auf @Mohit Phougat Antwort, wenn Sie einen Groovy mit @Grab Anmerkungen laufen haben, könnten Sie versuchen, solche Anmerkungen Ordnung wieder.

Wenn Sie alle Gläser aus bouncycastle.org hinzugefügt (in meinem Fall von crypto-159.zip), entfernen Sie einfach die, die für die JDKs, die für Sie nicht gelten. Es gibt Entlassungen. Sie haben wahrscheinlich nur brauchen, um die „jdk15on“ Gläser.

Diese Frage hat sich für eine lange Zeit gedauert, aber ich möchte Pech in etwas. Ich habe auf einem Frühlings-Projekt Herausforderung gearbeitet und ich entdeckte, dass in Eclipse IDE. Wenn Sie Maven oder Gradle für Frühjahr Boot-REST-APIs verwenden, müssen Sie die JUnit 4 oder 5 in dem Build-Pfad entfernen und schließen Junit in Ihrem pom.xml oder Gradle Build-Datei. Ich denke, dass zu yml Konfigurationsdatei gilt auch.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top