Java SecurityException: Die Unterzeichnerinformationen stimmen nicht überein

Ich habe meine Klassen wie gewohnt neu kompiliert und plötzlich die folgende Fehlermeldung erhalten. Warum? Wie kann ich es reparieren?

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)

Dies geschieht, wenn Klassen, die zum selben Paket gehören, aus verschiedenen JAR-Dateien geladen werden und diese JAR-Dateien Signaturen haben, die mit unterschiedlichen Zertifikaten signiert sind - oder möglicherweise häufiger mindestens eine signiert ist und eine oder mehrere andere nicht (einschließlich geladener Klassen) aus Verzeichnissen, da diese AFAIK nicht signiert werden können).

Stellen Sie also entweder sicher, dass alle JARs (oder zumindest diejenigen, die Klassen aus denselben Paketen enthalten) mit demselben Zertifikat signiert sind, oder entfernen Sie die Signaturen mit überlappenden Paketen aus dem Manifest von JAR-Dateien.

Ein einfacher Weg, dies zu umgehen, besteht darin, die Reihenfolge Ihrer importierten JAR-Dateien zu ändern, was über (Eclipse) möglich ist. Klicken Sie mit der rechten Maustaste auf Ihr Paket -> Erstellungspfad -> Erstellungspfad konfigurieren -> Referenzen und Bibliotheken -> Bestellen und Exportieren. Versuchen Sie, die Reihenfolge der Gläser zu ändern, die Signaturdateien enthalten.

A. Wenn Sie maven verwenden, ist eine nützliche Methode zum Debuggen von Kollisionsgläsern:

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

Seine Ausgabe:

[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 kollidierende Servlet-API 2.5 und javax.servlet 3.0.0.x.

B. Andere nützliche Hinweise (wie man die Sicherheitsausnahme debuggt und wie man Maven Deps ausschließt) finden Sie bei der Frage unter Signer-Informationen stimmen nicht überein .

In meinem Fall hatte ich die JAR-Version von BouncyCastle in meinem Bibliothekspfad 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 Hauptproblem war, dass ich die Hamcrest-Bibliothek zweimal aufgenommen habe. Einmal mit Maven Pom-Datei. Außerdem habe ich die JUnit 4-Bibliothek (die auch eine Hamcrest-Bibliothek enthält) zum Erstellungspfad des Projekts hinzugefügt. Ich musste einfach JUnit aus dem Erstellungspfad entfernen und alles war in Ordnung.

Dies kann bei cglib-instrumentierten Proxys auftreten, da CGLIB anstelle der Unterzeichnerinformationen der Anwendungszielklasse seine eigenen Unterzeichnerinformationen verwendet.

1. Nach dem Signieren Zugriff: dist \ lib
2. Finden Sie zusätzliche .jar
3. Mit Winrar extrahieren Sie nach einem Ordner (in "Ordnernamen" extrahieren)
4. Zugriff: META-INF / MANIFEST.MF
5. Löschen Sie jede Signatur wie folgt:

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

1. Speicher die Datei
2. Wieder Reißverschluss
3. Renaime ext .jar zurück
4. Bereits

Wenn Sie es in Eclipse ausführen, überprüfen Sie die Gläser aller Projekte, die dem Erstellungspfad hinzugefügt wurden. oder machen Sie Control-Shift-T und suchen Sie nach mehreren Gläsern, die demselben Namespace entsprechen. Entfernen Sie dann redundante oder veraltete Gläser aus dem Erstellungspfad des Projekts.

Ich habe dieses Problem mit Eclipse und JUnit 5. Meine Lösung ist von der vorherigen Antwort von user2066936 inspiriert. Es besteht darin, die Reihenfolge der Importbibliotheken neu zu konfigurieren:

1. Klicken Sie mit der rechten Maustaste auf das Projekt.
2. Öffnen Sie [Java Build Path].
3. Klicken Sie auf Bestellen und Exportieren.
4. Drücken Sie dann JUNIT auf die obere Priorität.

In meinem Fall war es ein Paketnamenkonflikt. Das aktuelle Projekt und die signierte referenzierte Bibliothek hatten ein Paket gemeinsam package.foo.utils. Ändern Sie einfach den aktuellen fehleranfälligen Paketnamen des Projekts in etwas anderes.

Ein bisschen zu alter Thread, aber da ich einige Zeit damit beschäftigt war, hier ist die Lösung (hoffe, es hilft jemandem)

Mein Szenario:

Der Paketname lautet: com.abc.def. Es gibt 2 JAR-Dateien, die Klassen aus diesem Paket enthalten, z. B. jar1 und jar2, dh einige Klassen sind in jar1 und andere in jar2 vorhanden. Diese JAR-Dateien werden mit demselben Keystore, jedoch zu unterschiedlichen Zeiten im Build (dh separat) signiert. Dies scheint zu einer unterschiedlichen Signatur für die Dateien in jar1 und jar2 zu führen.

Ich habe alle Dateien in jar1 abgelegt und alle zusammen erstellt (und signiert). Das Problem verschwindet.

PS: Die Paketnamen und JAR-Dateinamen sind nur Beispiele

Wenn Sie alle Gläser von bouncycastle.org hinzugefügt haben (in meinem Fall von crypto-159.zip), entfernen Sie einfach diejenigen für die JDKs, die für Sie nicht zutreffen. Es gibt Entlassungen. Sie benötigen wahrscheinlich nur die "jdk15on" -Gläser.

Diese Frage hat lange gedauert, aber ich möchte etwas einbringen. Ich habe an einer Spring-Projektherausforderung gearbeitet und dies in Eclipse IDE entdeckt. Wenn Sie Maven oder Gradle für Spring Boot Rest-APIs verwenden, müssen Sie Junit 4 oder 5 im Erstellungspfad entfernen und Junit in Ihre Erstellungsdatei pom.xml oder Gradle aufnehmen. Ich denke, das gilt auch für die yml-Konfigurationsdatei.

Dies geschieht auch, wenn Sie eine Datei mit unterschiedlichen Namen oder von unterschiedlichen Speicherorten zweimal einfügen, insbesondere wenn es sich um zwei verschiedene Versionen derselben Datei handelt.

Ich könnte es reparieren.

Grundursache: Dies ist ein häufiges Problem bei Verwendung der Sun JAXB-Implementierung mit signierten Jars. Im Wesentlichen versucht die JAXB-Implementierung, Reflexion zu vermeiden, indem eine Klasse generiert wird, die direkt auf die Eigenschaften zugreift, ohne Reflexion zu verwenden. Leider generiert es diese neue Klasse im selben Paket wie die Klasse, auf die zugegriffen wird. Daher kommt dieser Fehler.

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

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

Basierend auf der Antwort von @Mohit Phougat können Sie versuchen, solche Annotationen neu zu ordnen, wenn Sie einen Groovy mit @ Grab-Annotationen ausführen.

Dies ist mir bei der Verwendung von JUnit passiert. + Seien Sie versichert + Hamcrest. In diesem Fall fügen Sie Junit nicht hinzu, um den Pfad zu erstellen. Wenn Sie das Maven-Projekt haben, wurde dies von mir behoben. Unten finden Sie die Datei pom.xml

<dependencies>

    <dependency>
        <groupId>io.rest-assured</groupId>
        <artifactId>rest-assured</artifactId>
        <version>3.0.0</version>
    </dependency>

    <dependency>
        <groupId>org.hamcrest</groupId>
        <artifactId>hamcrest-all</artifactId>
        <version>1.3</version>
    </dependency>


    <!-- https://mvnrepository.com/artifact/junit/junit -->
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.12</version>

    </dependency>


</dependencies>

Ich habe JUNIT 5 ausgeführt und auch auf das externe Glas von Hamcrest verwiesen. Hamcrest ist aber auch Teil der JUNIT 5- Bibliothek. Daher muss ich die Reihenfolge der externen Hamecrest-JAR-Datei in der JUNIT 5- Bibliothek im Erstellungspfad ändern .