Java SecurityException: Subscriber information does not match

Question

I recompiled my classes as usual and unexpectedly received the following error message. What for? How can i fix this?

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

Answer 1

This happens when classes belonging to the same package are loaded from different JAR files, and these JAR files have signatures with different certificates - or, perhaps more often, at least one of them is signed, and one or more others - no (which includes classes loaded from directories, since AFAIK cannot be signed).

So, make sure that all JARs (or at least those that contain classes from the same packages) are signed using the same certificate or removed signatures from the JAR manifest of files with overlapping packages.

Answer 2

An easy way to get around this is to simply try changing the order of the imported jar files that can be made from (Eclipse). Right-click on your package → Build Path → Configure Build Path → Links and Libraries → Order and Export. Try changing the order of the jars containing the signature files.

Answer 3

but. If you are using maven, a useful way to debug conflicting banks:

 mvn dependency:tree 

For example, to exclude:

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

doing:

 mvn dependency:tree|grep servlet 

His conclusion:

 [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 

shows servlet-api 2.5 and javax.servlet 3.0.0.x fail.

B. Other useful tips (how to debug a security exception and how to exclude maven deps) are in the Question about subscribers does not match .

Answer 4

In my case, I had a duplicated version of the JAR BouncyCastle in my library path: S

Answer 5

I had a similar exception:

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

The root problem was that I turned on the Hamcrest library twice. After using the Maven pom file. And I also added the JUnit 4 library (which also contains the Hamcrest library) to the project build path. I just had to remove JUnit from the build path and everything was fine.

Answer 6

This can happen with cglib-instrumented proxies because CGLIB uses its own subscriber information instead of the subscriber information of the target application class.

Answer 7

• After the access sign: dist \ lib
• Find More .jar
• Using Winrar, you extract for the folder (extract to "folder name")
• Access: META-INF / MANIFEST.MF
• Delete each signature as follows:

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

• Save file
• Zip again
• Renaime ext to.jar back
• Already

Answer 8

If you run it in Eclipse, check the banks of any projects added to the build path; or do control-shift-T and scan multiple jars corresponding to the same namespace. Then remove the excess or obsolete banks from the project build path.

Answer 9

In my case, it was a package name conflict. There is one common package.foo.utils package in the current project and the signed link library. Just changed the current name of the package, prone to project errors, to something else.

Answer 10

A little too old thread, but since I got stuck on this for a while, here is the fix (I hope this helps someone)

My scenario:

Package Name: com.abc.def. There are 2 jar files that 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 build times (i.e., separately). This seems to lead to a different signature for the files in jar1 and jar2.

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

PS: package names and jar file names are examples

Answer 11

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

Answer 12

I could fix it.

Root cause: This is a common problem when using Sun JAXB with signed banks. Essentially, the JAXB implementation tries to avoid reflection by creating a class for direct access to properties without using reflection. Unfortunately, it generates this new class in the same package as the class accessed, where this error comes from.

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

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

Answer 13

Based on @Mohit Phougat's answer, if you use Groovy with @Grab annotations, you can try to override such annotations.

Answer 14

If you added all the jar files from bouncycastle.org (in my case from crypto-159.zip), simply delete those JDK files that are not relevant to you. There are layoffs. You probably only need jdk15on cans.

Answer 15

This issue lasted a long time, but I want to discuss something. I was working on a Spring project and discovered this in the Eclipse IDE. If you are using Maven or Gradle for the Spring Boot Rest API, you must remove Junit 4 or 5 in the build path and include Junit in your pom.xml or Gradle build file. I think this applies to the yml configuration file as well.