Java SecurityException: informacje podpisującego nie są zgodne

121

Ponownie skompilowałem swoje klasy jak zwykle i nagle otrzymałem następujący komunikat o błędzie. Czemu? Jak mogę to naprawić?

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)
Szczery
źródło

Odpowiedzi:

137

Dzieje się tak, gdy klasy należące do tego samego pakietu są ładowane z różnych plików JAR, a te pliki JAR mają podpisy podpisane różnymi certyfikatami - lub, być może częściej, przynajmniej jeden jest podpisany, a co najmniej jeden nie (co obejmuje załadowane klasy z katalogów, ponieważ te AFAIK nie mogą być podpisane).

Więc albo upewnij się, że wszystkie pliki JAR (lub przynajmniej te, które zawierają klasy z tych samych pakietów) są podpisane tym samym certyfikatem, albo usuń podpisy z manifestu plików JAR z nakładającymi się pakietami.

Michael Borgwardt
źródło
Użyłem tego samego certyfikatu, ale wygasł, jak go odnowić?
Frank
34
Czy ktoś może wyjaśnić początkującym, jak to zrobić? Zacząłem pracować z Javą i Spring tydzień temu i jestem zagubiony.
mghz
Mam podobny problem, ale jest w hibernacji słoików. Te słoiki nie są podpisane, nadal mam ten problem. Czemu? Proszę odnieść się do stackoverflow.com/questions/24386463/ ...
user613114
czy istnieje jakiś konkretny proces podpisywania wielu słoików tym samym certyfikatem. Próbowałem podpisywać słoiki (jeden po drugim) tym samym certyfikatem, ale nadal otrzymałem następujący wyjątek: informacje o sygnatariuszu nie są zgodne z informacjami o sygnatariuszu innych klas w tym samym pakiecie
vegeta
@vegeta: przepraszam, nie mam doświadczenia z procedurą podpisywania.
Michael Borgwardt
45

Prostym sposobem obejścia tego problemu jest zmiana kolejności importowanych plików jar, co można zrobić z (Eclipse). Kliknij prawym przyciskiem myszy pakiet -> Ścieżka kompilacji -> Konfiguruj ścieżkę kompilacji -> Referencje i biblioteki -> Zamów i eksportuj. Spróbuj zmienić kolejność słoików, które zawierają pliki sygnatur.

Mohit Phougat
źródło
Mam podpisany plik jar do przetestowania, testuję pliki klas z tym samym pakietem, junit, jre, inne jars. Jaka jest właściwa kolejność zaćmienia? Nie jestem pewien, czy wypróbowałem jeszcze wszystkie kombinacje. Ale nie wyszedł poza program ładujący klasy SecurityException
datafiddler
Dzięki za to rozwiązanie, właśnie zmieniłem kolejność junit5 i mojego hamcrest-all.jar i teraz moje testy znów działają :)
Wallnussfolie
41

O. Jeśli używasz mavena, przydatnym sposobem debugowania kolizji słoików jest:

mvn dependency:tree

Na przykład dla wyjątku:

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

my robimy:

mvn dependency:tree|grep servlet

Jego wydajność:

[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

pokazuje kolizję servlet-api 2.5 i javax.servlet 3.0.0.x.

B. Inne przydatne wskazówki (jak debugować wyjątek bezpieczeństwa i jak wykluczyć deps maven) znajdują się w pytaniu o niezgodności informacji podpisującego .

Eugene Gr. Philippov
źródło
Używam STS jako IDE, przełączyłem konsolę na konsolę maven i próbowałem uruchomić tam powyższe polecenie, ale nic się nie stało ... Wygląda na to, że konsola maven w STS / eclipse to tylko po to, aby wyświetlić wyjście, ale nie akceptuje żadnych poleceń. A może się mylę?
nanosoft
1
nanosoft, Wygląda na to, że Twoje pytanie jest związane z STS, więc możesz utworzyć dla niego nowe pytanie najwyższego poziomu. mvn na pewno akceptuje argumenty wiersza poleceń.
Eugene Gr. Philippov
@ EugeneGr.Philippov, jak to jest powiązane? Jaka jest zależność: drzewo pokazuje wersję słoików, która nie jest związana z sygnatariuszem
Gavriel
@Gavriel Nie kopałem zbyt wiele, ale kiedy pozbywasz się konfliktów, wyjątek się nie dzieje.
Eugene Gr. Philippov
Może to być prawdą w niektórych przypadkach, ale nie we wszystkich. Na przykład różne artefakty w grupie com.microsoft.azure wydają się być kompilowane z wielu źródeł, więc niektóre z nich nie mają nawet tej samej wersji. W większości przypadków posiadanie wielu wersji nie powoduje błędu (nawet jeśli wtyczka egzekwująca ostrzega lub zawodzi z tego powodu)
Gavriel
23

W moim przypadku zduplikowałem wersję JAR BouncyCastle w mojej ścieżce do biblioteki: S

Cedric Simon
źródło
2
To samo przytrafiło się mnie. Usunięcie wszystkich słoików BC i załadowanie odpowiednich wersji rozwiązało problem.
Broken_Window
1
@Cedric - Taki sam BouncyCastle był dla mnie
nanosoft
W moim przypadku było tak, ponieważ spring-cloud inside wymaga jdk15on, a ja używałem bcprov-jdk16 do mojego projektu.
Glats
8

Miałem podobny wyjątek:

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

Główny problem polegał na tym, że dwukrotnie włączyłem bibliotekę Hamcrest. Po użyciu pliku pom Maven. Dodałem także bibliotekę JUnit 4 (która zawiera również bibliotekę Hamcrest) do ścieżki budowania projektu. Po prostu musiałem usunąć JUnit ze ścieżki kompilacji i wszystko było w porządku.

Marvin
źródło
6

Taka sytuacja może wystąpić w przypadku serwerów proxy z instrumentami cglib, ponieważ CGLIB używa własnych informacji o sygnatariuszu zamiast informacji o sygnatariuszu klasy docelowej aplikacji.

Jarek Przygódzki
źródło
4
Co możemy zrobić, jeśli tak jest?
Leandro
@Jarek: jakie byłoby tutaj rozwiązanie? czy możemy skorzystać z tego rozwiązania? developer.jboss.org/thread/241718
gaurav
@gaurav Przestaliśmy używać podpisanych słoików. Były potrzebne tylko do Java Web Start i dawno zostały porzucone.
Jarek Przygódzki
4
  1. Po podpisaniu dostęp: dist \ lib
  2. Znajdź dodatkowy plik .jar
  3. Używając Winrar, możesz wypakować dla folderu (wypakować do „nazwa folderu”)
  4. Dostęp: META-INF / MANIFEST.MF
  5. Usuń każdy podpis w ten sposób:

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

  1. Zapisz plik
  2. Zip ponownie
  3. Renaime ext do .jar z powrotem
  4. Już
Douglas Tybel
źródło
Mam pewne problemy zgodnie z twoją radą: stackoverflow.com/questions/33988136/ ...
Zadzwoń
2

Jeśli uruchamiasz go w Eclipse, sprawdź pliki JAR wszystkich projektów dodanych do ścieżki kompilacji; lub wykonaj Ctrl-Shift-T i wyszukaj wiele plików jar pasujących do tej samej przestrzeni nazw. Następnie usuń zbędne lub nieaktualne pliki JAR ze ścieżki kompilacji projektu.


źródło
2

Mam ten problem z Eclipse i JUnit 5. Moje rozwiązanie jest inspirowane poprzednią odpowiedzią użytkownika2066936. Chodzi o zmianę kolejności bibliotek importu:

  1. Kliknij projekt prawym przyciskiem myszy.
  2. Otwórz [Ścieżkę budowania Java].
  3. Kliknij Zamów i eksportuj.
  4. Następnie przesuń JUNIT do wyższego priorytetu.
PROMIEŃ
źródło
1

W moim przypadku był to konflikt nazw pakietów. Bieżący projekt i podpisana biblioteka, do której się odwołuje, miały jeden wspólny pakiet package.foo.utils. Właśnie zmieniłem nazwę pakietu podatnego na błędy projektu na inną.

buzz2buzz
źródło
1

Trochę za stary wątek, ale ponieważ utknąłem w tym przez dłuższy czas, oto poprawka (mam nadzieję, że to komuś pomoże)

Mój scenariusz:

Nazwa pakietu to: com.abc.def. Istnieją 2 pliki jar, które zawierają klasy z tego pakietu, np. Jar1 i jar2, tj. Niektóre klasy znajdują się w jar1, a inne w jar2. Te pliki jar są podpisywane przy użyciu tego samego magazynu kluczy, ale w różnych momentach kompilacji (tj. Oddzielnie). Wydaje się, że skutkuje to różnymi sygnaturami dla plików w jar1 i jar2.

Umieściłem wszystkie pliki w jar1 i zbudowałem (i podpisałem) je wszystkie razem. Problem znika.

PS: Nazwy pakietów i nazwy plików jar są tylko przykładami

mukeshkumar
źródło
1

Jeśli dodałeś wszystkie słoiki z bouncycastle.org (w moim przypadku z crypto-159.zip), po prostu usuń te dla JDK, które Cię nie dotyczą. Istnieją zwolnienia. Prawdopodobnie potrzebujesz tylko słoików „jdk15on”.

Bertrand_Szoghy
źródło
To był dokładnie mój problem, wdrażałem aplikację BC na serwerze aplikacji, który ma już niestandardową podpisaną wersję tego samego w swoim udostępnionym folderze libs, rozwiązaniem było ich usunięcie i użycie nowszych.
GChiappe
1

To pytanie trwało długo, ale chcę w coś odpowiedzieć. Pracowałem nad wyzwaniem projektu Spring i odkryłem to w Eclipse IDE. Jeśli używasz Maven lub Gradle do Spring Boot Rest API, musisz usunąć Junit 4 lub 5 ze ścieżki kompilacji i dołączyć Junit do pliku kompilacji pom.xml lub Gradle. Myślę, że dotyczy to również pliku konfiguracyjnego yml.

tksilicon
źródło
0

Dzieje się tak również wtedy, gdy dwa razy dołączysz jeden plik o różnych nazwach lub z różnych lokalizacji, zwłaszcza jeśli są to dwie różne wersje tego samego pliku.

Tomas Walek
źródło
Przepraszam, ale nie rozumiem. Jaki rodzaj pliku? W moim przypadku błąd dotyczy klasy org.jboss.security.xacml.jaxb.PoliciesType i jestem pewien, że znajduje się on tylko w słoiku dostarczanym z JBoss EAP 5.2 (/EnterprisePlatform-5.2.0/jboss-eap-5.2/ jboss-as / common / lib / jbossxacml.jar)
Leandro
0

Mógłbym to naprawić.

Główna przyczyna: Jest to częsty problem podczas używania implementacji Sun JAXB z podpisanymi plikami JAR. Zasadniczo implementacja JAXB próbuje uniknąć odbicia, generując klasę, aby uzyskać bezpośredni dostęp do właściwości bez używania odbicia. Niestety, generuje tę nową klasę w tym samym pakiecie, co klasa, do której uzyskiwany jest dostęp, skąd pochodzi ten błąd.

Rozwiązanie: Dodaj następującą właściwość systemową, aby wyłączyć optymalizacje JAXB, które nie są zgodne z podpisanymi plikami JAR: -Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize = true

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

Leandro
źródło
0

Opierając się na odpowiedzi @Mohit Phougat, jeśli używasz Groovy z adnotacjami @Grab, możesz spróbować ponownie zamówić takie adnotacje.

ATorras
źródło
0

zdarzyło mi się to podczas używania JUnit + spokojnie + hamcrest, w tym przypadku nie dodawaj junita do ścieżki budowania, jeśli masz projekt maven, to rozwiązało mnie, poniżej jest 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>
Naveen
źródło
0

Biegałam JUnit 5 a także przedstawieniu Hamcrest zewnętrznego jar. Ale Hamcrest jest również częścią biblioteki JUNIT 5 . Więc muszę zmienić kolejność zewnętrznego pliku jar Hamecrest w bibliotece JUNIT 5 w ścieżce kompilacji.

wprowadź opis obrazu tutaj

D Saggu
źródło