Java SecurityException: signer information does not match

Question

I recompiled my classes as usual, and suddenly got the following error message. Why? How can I fix it?

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)

Intercalation

Does this answer your question? hamcrest tests always fail – Herthahertz

Answer 1

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

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

Jura

I used the same certificate, but it's expired, how to re-new it ? – Intercalation

Can someone explain to newbies how to do that? I started working with java and spring a week ago and i'm lost. – Prestissimo

I am facing similar issue, but its in hibernate jars. These jars are not signed, still i face this issue. Why? Please refer to #24386963 – Keefer

is there any specific process to sign multiple jars with same certificate. I tried signing jars(one by one) with same certificate, but still got following exception: signer information does not match signer information of other classes in the same package – Morphosis

@vegeta: sorry, I don't really have any experience with the signing procedure. – Jura

Do you know how to remove signature from a signed dependency jar when it is used by an unsigned parent entity? – Jerricajerrie

In case anyone runs into exactly what I ran into... I had a couple AWS dependencies and I was hitting this when bumping the version on one of them. The solution was to (1) identify the other jar which was having the package collision, and then (2) bump the version on that other jar. – Woolworth

Exactly, the issue was the same. I was using bouncy castle in my project and everything was OK. Suddenly started giving this error after included jradius. – Casimiracasimire

Screenshot shared listing the dependencies after solved tekmx.com/wp-content/uploads/2020/08/… – Casimiracasimire

@Prestissimo In 'Package Explorer' expand each Dependency packages and look for the package in the error. You should have at least two imports of the same package listed. You can remove all those instances that you don't need. Error should be gone now!!! – Humanist

Answer 2

A simple way around it is just try changing the order of your imported jar files which can be done from (Eclipse). Right click on your package -> Build Path -> Configure build path -> References and Libraries -> Order and Export. Try changing the order of jars which contain signature files.

Vasiliki

I have a signed jar file to be tested, test class files with the same package, junit, jre, other jars. Which is the proper order in eclipse ? Not sure I tried all combinations yet. But did not come beyond the class loader SecurityException – Estovers

Thanks for this solution, I just changed the order of junit5 and my hamcrest-all.jar and now my tests are working again :) – Ennoble

Answer 3

A. If you use Maven, a useful way to debug clashing jars is:

mvn dependency:tree

For example, for an exception:

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

we do:

mvn dependency:tree|grep servlet

Its output:

[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 clashing servlet-api 2.5 and javax.servlet 3.0.0.x.

B. Other useful hints (how to debug the security exception and how to exclude Maven deps) are at the question Signer information does not match.

Gallant

I am using STS as an IDE, I switched the console to maven console and tried to run above command there but nothing happened... Looks that maven console in STS/eclipse it just to display output but doesn't accept any commands. Or am I wrong? – Carcinomatosis

nanosoft, It seems that your question is STS-related, so you could create a new top-level question for it. mvn for sure accepts command line arguments. – Gallant

@EugeneGr.Philippov how is this related? What the dependency:tree shows is the version of the jars, that's not related to the signer – Soda

@Soda I did not dig much, but when you get rid of conflicts, the exception doesn't happen. – Gallant

That might be true in some cases but not in all. For example different artifacts in com.microsoft.azure group seem to be compiled from multiple sources, so some of them don't even have the same version. And in most cases having multiple versions don't produce the error (even if the enforcer plugin warns or fails because of it) – Soda

@Soda it seems that the exception is related to clashing versions and their debugging. Yes I speak vaguely, but knowing how to debug maven dependency trees helped me to get rid of the signing exceptions. This is one of a ways these things might very indirectly be related to each other. A distant relation that is a vague thing but helpful for some. – Gallant

Answer 4

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

Potoroo

The same happened to me. Removing all of the BC jars and loading the right versions solved it. – Diablerie

@Cedric - Same BouncyCastle was the case for me – Carcinomatosis

In my case was because spring-cloud inside requires jdk15on and i was using bcprov-jdk16 for my project. – Frivolous

seems to be a common issue since they maintain different artifacts for the target jdk – Spurge

Answer 5

I had a similar exception:

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

The root problem was that I included the Hamcrest library twice. Once using Maven pom file. And I also added the JUnit 4 library (which also contains a Hamcrest library) to the project's build path. I simply had to remove JUnit from the build path and everything was fine.

Moonlit

There was a JUnit in libraries classpath. removing it do the job – Bess

This solution applies to JUnit 5, too. – Loadstar

Answer 6

This can occur with the cglib-instrumented proxies because CGLIB uses his own signer information instead of the signer information of the application target class.

Dolabriform

What can we do if this is the case? – Ectoparasite

@Jarek : what would be the solution here? can we use this solution? developer.jboss.org/thread/241718 – Omniscience

@gaurav We stopped using signed jars. They were only needed for Java Web Start, and it's been long abandoned. – Selfhelp

Older versions of Mockito used CGLIB, and so this could potentially lead to a similar error that OP was having. Newer versions of Mockito don't use CGLIB, and so upgrading versions solves this problem. I posted an answer with more details. – Peoples

Answer 7

1. After sign, access: dist\lib
2. Find extra .jar
3. Using Winrar, You extract for a folder (extract to "folder name") option
4. Access: META-INF/MANIFEST.MF
5. Delete each signature like that:

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

1. Save the file
2. Zip again
3. Renaime ext to .jar back
4. Already

Sometimes

I'm having some issues following your advice: #33988636 – Incontinent

Answer 8

A bit of an old thread but since I was stuck for quite some time on this, here's the fix (hope it helps someone).

My scenario:

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 in different signatures 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

Danielladanielle

Answer 9

I am having this problem with Eclipse and JUnit 5. My solution is inspired by the previous answer by user2066936 It is to reconfig the ordering of the import libraries:

1. Right click the project.
2. Open [Java Build Path].
3. Click Order and Export.
4. Then push JUNIT to upper priority.

Tuyettv

Answer 10

If you're running it in Eclipse, check the jars of any projects added to the build path; or do control-shift-T and scan for multiple jars matching the same namespace. Then remove redundant or outdated jars from the project's build path.

Gamester

Answer 11

In my case it was a package name conflict. Current project and signed referenced library had one package in common package.foo.utils. Just changed the current project error-prone package name to something else.

Wingo

Answer 12

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.

Wieldy

This was exactly my issue, I was deploying a BC application in an application server that already have a custom signed version of the same in its shared libs folder, solution was to remove them and use the newer ones. – Jumpoff

Putting bcprov and bcmail same on jdk15on version helped us. Thanks – Gilchrist

Answer 13

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.

Omniumgatherum

Answer 14

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.

Lakeesha

I am sorry but I don't understand. What kind of file? In my case the error is with the class org.jboss.security.xacml.jaxb.PoliciesType and I am sure it is only in a jar that comes with JBoss EAP 5.2 (/EnterprisePlatform-5.2.0/jboss-eap-5.2/jboss-as/common/lib/jbossxacml.jar) – Ectoparasite

Answer 15

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

Ectoparasite

Answer 16

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

Consultation

Answer 17

This happened to me when using JUnit + REST Assured + Hamcrest. In this case, don't add JUnit to your build path. If you have a Maven project, the below pom.xml file resolved this for me:

<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>

Epstein

Can you please comment pom.xml example? junit is added to build path in it – Crustaceous

Answer 18

I was running JUNIT 5 and was also referencing Hamcrest external jar, but Hamcrest is also a part of the JUNIT 5 library. So, I moved the order of the external Hamcrest jar file to be above the JUNIT 5 library in the build path.

Forsooth

Answer 19

I was getting a similar error when trying to use Mockito:

"$$FastClassByMockitoWithCGLIB$$abb8f5a0"'s signer information does not match signer information of other classes in the same package"

I was using an old version of Mockito, and upgrading to the latest Mockito version solved this problem. The issue was with CGLIB as mentioned in one of the other answers. In newer versions, Mockito replaces CGLIB with ByteBuddy, and so the problem goes away. I also had to add the new ByteBuddy jars to the classpath in Eclipse to get Mockito working again.

Peoples