Java SecurityException : 서명자 정보가 일치하지 않습니다.
답변:
이것은 동일한 패키지에 속하는 클래스가 다른 JAR 파일에서로드되고 해당 JAR 파일에 다른 인증서로 서명 된 서명이 있거나 더 자주, 적어도 하나는 서명되고 하나 이상의 다른 것은 서명되지 않은 경우 (로드 된 클래스 포함) 해당 AFAIK에 서명 할 수 없기 때문에 디렉터리에서).
따라서 모든 JAR (또는 최소한 동일한 패키지의 클래스를 포함하는 JAR)이 동일한 인증서를 사용하여 서명되었는지 확인하거나 패키지가 겹치는 JAR 파일의 매니페스트에서 서명을 제거하십시오.
간단한 방법은 (Eclipse)에서 수행 할 수있는 가져온 jar 파일의 순서를 변경하는 것입니다. 패키지-> 빌드 경로-> 빌드 경로 구성-> 참조 및 라이브러리-> 주문 및 내보내기를 마우스 오른쪽 단추로 클릭하십시오. 서명 파일이 포함 된 jar의 순서를 변경해보십시오.
A. maven을 사용하는 경우 충돌하는 jar를 디버깅하는 유용한 방법은 다음과 같습니다.
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 does 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 계측 프록시에서 발생할 수 있습니다.
- 서명 후 액세스 : dist \ lib
- 여분의 .jar 찾기
- Winrar를 사용하여 폴더를 추출합니다 ( "폴더 이름"으로 추출) 옵션
- 액세스 : META-INF / MANIFEST.MF
- 다음과 같이 각 서명을 삭제하십시오.
이름 : net / sf / jasperreports / engine / util / xml / JaxenXPathExecuterFactory.c lass SHA-256-Digest : q3B5wW + hLX / + lP2 + L0 / 6wRVXRHq1mISBo1dkixT6Vxc =
- 파일 저장
- 다시 압축
- Renaime ext to .jar back
- 이미
Eclipse에서 실행하는 경우 빌드 경로에 추가 된 프로젝트의 jar를 확인하십시오. 또는 control-shift-T를 수행하고 동일한 네임 스페이스와 일치하는 여러 jar를 검색합니다. 그런 다음 프로젝트의 빌드 경로에서 중복되거나 오래된 jar를 제거합니다.
너무 오래된 스레드이지만 이것에 대해 꽤 오랫동안 붙어 있었기 때문에 여기에 수정 사항이 있습니다 (누군가에게 도움이되기를 바랍니다)
내 시나리오 :
패키지 이름은 com.abc.def입니다. 이 패키지의 클래스를 포함하는 2 개의 jar 파일 (예 : jar1 및 jar2)이 있습니다. 즉 일부 클래스는 jar1에 있고 다른 클래스는 jar2에 있습니다. 이러한 jar 파일은 동일한 키 저장소를 사용하여 서명되지만 빌드에서 다른 시간에 (즉, 개별적으로) 서명됩니다. 이는 jar1 및 jar2의 파일에 대해 다른 서명을 초래하는 것 같습니다.
모든 파일을 jar1에 넣고 모두 함께 빌드 (및 서명)했습니다. 문제는 사라집니다.
추신 : 패키지 이름과 jar 파일 이름은 예제 일뿐입니다.
bouncycastle.org (내 경우에는 crypto-159.zip)에서 모든 항아리를 추가 한 경우 적용되지 않는 JDK 용 항아리 만 제거하십시오. 중복이 있습니다. "jdk15on"항아리 만 필요합니다.
내가 고칠 수 있습니다.
근본 원인 : 이는 서명 된 jar와 함께 Sun JAXB 구현을 사용할 때 발생하는 일반적인 문제입니다. 기본적으로 JAXB 구현은 리플렉션을 사용하지 않고 속성에 직접 액세스하는 클래스를 생성하여 리플렉션을 피하려고합니다. 불행히도,이 오류가 발생하는 액세스되는 클래스와 동일한 패키지에서이 새 클래스를 생성합니다.
해결 방법 : 서명 된 jar와 호환되지 않는 JAXB 최적화를 비활성화하려면 다음 시스템 속성을 추가하십시오. -Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize = true
이것은 JUnit + rest assured + hamcrest를 사용할 때 나에게 일어났습니다.이 경우 빌드 경로에 junit을 추가하지 마십시오.
<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>