Java SecurityException : 서명자 정보가 일치하지 않습니다

Java SecurityException : 서명자 정보가 일치하지 않습니다

---

평소와 같이 클래스를 다시 컴파일하고 갑자기 다음과 같은 오류 메시지가 나타납니다. 왜? 어떻게 고칠 수 있습니까?

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)

---

이는 동일한 패키지에 속하는 클래스가 다른 JAR 파일에서로드되고 해당 JAR 파일에 다른 인증서로 서명 된 서명이 있거나 더 자주 하나 이상의 서명되고 하나 이상의 다른 클래스에 서명되지 않은 경우 (로드 된 클래스 포함) 해당 AFAIK에 서명 할 수 없으므로 디렉토리에서).

따라서 모든 JAR (또는 최소한 동일한 패키지의 클래스를 포함하는 JAR)에 동일한 인증서를 사용하여 서명하거나 패키지가 겹치는 JAR 파일의 매니페스트에서 서명을 제거하십시오.

---

간단한 방법은 (Eclipse)에서 수행 할 수있는 가져온 jar 파일의 순서를 변경하는 것입니다. 패키지-> 빌드 경로-> 빌드 경로 구성-> 참조 및 라이브러리-> 주문 및 내보내기를 마우스 오른쪽 단추로 클릭하십시오. 서명 파일이 들어있는 jar의 순서를 변경하십시오.

---

A. maven을 사용하는 경우 충돌 항아리를 디버깅하는 유용한 방법은 다음과 같습니다.

mvn dependency:tree

예를 들어, 예외의 경우 :

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

우리는하다:

mvn dependency:tree|grep servlet

출력 :

[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

servlet-api 2.5와 javax.servlet 3.0.0.x의 충돌을 보여줍니다.

B. 다른 유용한 힌트 (보안 예외를 디버그하는 방법과 maven deps를 제외하는 방법)는 Signer information is not match에 있습니다.

---

내 경우에는 라이브러리 경로에 BouncyCastle의 JAR 버전을 복제했습니다.

---

비슷한 예외가있었습니다.

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

근본적인 문제는 Hamcrest 라이브러리를 두 번 포함했다는 것입니다. Maven pom 파일을 사용한 후 또한 JUnit 4 라이브러리 (Hamcrest 라이브러리도 포함)를 프로젝트의 빌드 경로에 추가했습니다. 빌드 경로에서 JUnit을 제거해야했고 모든 것이 정상이었습니다.

---

CGLIB는 애플리케이션 대상 클래스의 서명자 정보 대신 자신의 서명자 정보를 사용하기 때문에 cglib 계측 프록시에서 발생할 수 있습니다.

---

1. 서명 후 액세스 : dist \ lib
2. 추가 .jar 찾기
3. Winrar를 사용하여 폴더를 추출합니다 ( "폴더 이름"으로 추출) 옵션
4. 액세스 : META-INF / MANIFEST.MF
5. 다음과 같이 각 서명을 삭제하십시오.

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

1. 파일을 저장하십시오
2. 다시 지퍼로
3. .jar 로의 Renaime ext
4. 이미

---

Eclipse에서 실행중인 경우 빌드 경로에 추가 된 프로젝트의 jar을 확인하십시오. 또는 control-shift-T를 수행하고 동일한 네임 스페이스와 일치하는 여러 jar을 스캔하십시오. 그런 다음 프로젝트 빌드 경로에서 중복되거나 오래된 항아리를 제거하십시오.

---

제 경우에는 패키지 이름이 충돌했습니다. 현재 프로젝트와 서명 된 참조 라이브러리에는 공통된 하나의 패키지가 package.foo.utils있습니다. 현재 프로젝트 오류가 발생하기 쉬운 패키지 이름을 다른 것으로 변경했습니다.

---

조금 오래된 스레드이지만이 문제에 꽤 오랫동안 붙어 있기 때문에 여기에 수정 사항이 있습니다 (누군가를 돕기를 바랍니다)

내 시나리오 :

The package name is : com.abc.def. There are 2 jar files which contain classes from this package say jar1 and jar2 i.e. some classes are present in jar1 and others in jar2. These jar files are signed using the same keystore but at different times in the build (i.e. separately). That seems to result into different signature for the files in jar1 and jar2.

I put all the files in jar1 and built (and signed) them all together. The problem goes away.

PS: The package names and jar file names are only examples

---

This also happens if you include one file with different names or from different locations twice, especially if these are two different versions of the same file.

---

I could fix it.

Root Cause: This is a common issue when using the Sun JAXB implementation with signed jars. Essentially the JAXB implementation is trying to avoid reflection by generating a class to directly access the properties without using reflection. Unfortunately, it generates this new class in the same package as the class being accessed which is where this error comes from.

Resolution: Add the following system property to disable the JAXB optimizations that are not compatible with signed jars: -Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize=true

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

---

Based on @Mohit Phougat response, if you are running a Groovy with @Grab annotations, you could try to re-order such annotations.

---

If you added all the jars from bouncycastle.org (in my case from crypto-159.zip), just remove the ones for the JDKs that do not apply to you. There are redundancies. You probably only need the "jdk15on" jars.

---

This question has lasted for a long time but I want to pitch in something. I have been working on a Spring project challenge and I discovered that in Eclipse IDE. If you are using Maven or Gradle for Spring Boot Rest APIs, you have to remove the Junit 4 or 5 in the build path and include Junit in your pom.xml or Gradle build file. I guess that applies to yml configuration file too.

참고URL : https://stackoverflow.com/questions/2877262/java-securityexception-signer-information-does-not-match