Recopilé mis clases como de costumbre y de repente recibí el siguiente mensaje de error. ¿Por qué? ¿Cómo puedo arreglarlo?Java SecurityException: la información del firmante no coincide con
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)
Esto ocurre cuando las clases pertenecientes al mismo paquete se cargan desde diferentes archivos JAR y los archivos JAR tienen firmas firmado con diferentes certificados - o, tal vez con más frecuencia, al menos una está firmada y otra u otras are not (que incluye clases cargadas desde directorios ya que esos AFAIK no se pueden firmar).
Por lo tanto, asegúrese de que todos los JAR (o al menos los que contienen clases de los mismos paquetes) estén firmados con el mismo certificado o elimine las firmas del manifiesto de archivos JAR con paquetes superpuestos.
Una manera simple de evitarlo es simplemente cambiando el orden de los archivos jar importados que se pueden hacer desde (Eclipse). Haga clic derecho en su paquete -> Ruta de compilación -> Configurar ruta de compilación -> Referencias y bibliotecas -> Ordenar y exportar. Intente cambiar el orden de los frascos que contienen archivos de firma.
gracias. esto resolvió mi problema – TechFind
Tengo un archivo jar firmado para probar, archivos de clase de prueba con el mismo paquete, junit, jre, otros jarros. ¿Cuál es el orden correcto en eclipse? No estoy seguro de haber probado todas las combinaciones todavía. Pero no vino más allá del cargador de clases SecurityException – datafiddler
Esto puede ocurrir con los proxys equipados con cglib porque CGLIB utiliza su propia información de firmante en lugar de la información de firmante de la clase de destino de la aplicación.
¿Qué podemos hacer si este es el caso? – Leandro
Nombre: red/sf/jasperreports/motor/util/xml/JaxenXPathExecuterFactory.c lass SHA-256-Digesto: q3B5wW + HLX/+ LP2 + L0/6wRVXRHq1mISBo1dkixT6Vxc =
Tengo algunos problemas para seguir su consejo: http://stackoverflow.com/questions/33988136/java-security-exception-birt-and-apache-poi-hack – Ring
Esto también ocurre si incluye dos veces un archivo con nombres diferentes o de ubicaciones diferentes, especialmente si se trata de dos versiones diferentes del mismo archivo.
Lo siento pero no entiendo. ¿Qué tipo de archivo? En mi caso, el error es con la clase org.jboss.security.xacml.jaxb.PoliciesType y estoy seguro de que solo está en un jar que viene con JBoss EAP 5.2 (/EnterprisePlatform-5.2.0/jboss-eap-5.2/ jboss-as/common/lib/jbossxacml.jar) – Leandro
A. Si utiliza Maven, una forma útil para depurar frascos choque es:
mvn dependency:tree
Por ejemplo, una excepción:
java.lang.SecurityException: class "javax.servlet.HttpConstraintElement"'s signer information does not match signer information of other classes in the same package
que hacemos:
mvn dependency:tree|grep servlet
Su salida:
[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
muestra las diferencias entre servlet-api 2.5 y javax.servlet 3.0.0.x.
B.Otras sugerencias útiles (cómo depurar la excepción de seguridad y cómo excluir a los expertos) están en la pregunta al Signer information does not match.
Estoy usando STS como un IDE, cambié la consola a la consola de maven e intenté ejecutar el comando de arriba pero no pasó nada ... Parece que la consola de maven en STS/eclipse solo para mostrar el resultado pero no acepta ningún comando. ¿O estoy equivocado? – nanosoft
nanosoft, Parece que su pregunta está relacionada con STS, por lo que podría crear una nueva pregunta de nivel superior para ella. mvn seguramente acepta argumentos de línea de comando. –
Podría arreglarlo.
Causa raíz: Este es un problema común cuando se utiliza la implementación de Sun JAXB con frascos firmados. Esencialmente, la implementación de JAXB trata de evitar la reflexión generando una clase para acceder directamente a las propiedades sin usar la reflexión. Desafortunadamente, genera esta nueva clase en el mismo paquete que la clase a la que se accede y de donde proviene este error.
Resolución: Añadir la siguiente propiedad del sistema para desactivar las optimizaciones JAXB que no son compatibles con los tarros firmados: -Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize = true
en mi caso, me había duplicado versión JAR de BouncyCastle en mi ruta de la biblioteca: S
Lo mismo me pasó a mí. Quitar todos los frascos de BC y cargar las versiones correctas lo resolvió. –
@Cedric - Same BouncyCastle fue el caso para mí – nanosoft
Si se está ejecutando en Eclipse, compruebe los frascos de los proyectos agregados a la trayectoria de la estructura; o haga control-shift-T y busque múltiples jar que coincidan con el mismo espacio de nombres. A continuación, elimine los archivos redundantes u obsoletos de la ruta de compilación del proyecto.
Según la respuesta de @Mohit Phougat, si está ejecutando un Groovy con anotaciones @Grab, puede intentar volver a ordenar tales anotaciones.
En mi caso, era un conflicto de nombre de paquete. El proyecto actual y la biblioteca referenciada firmada tenían un paquete en común package.foo.utils. Simplemente cambié el nombre del paquete propenso a errores del proyecto actual a otra cosa.
Un poco demasiado viejo hilo, pero ya me he quedado atrapado desde hace bastante tiempo en esto, aquí está la solución (espero que ayude a alguien)
Mi escenario:
El nombre del paquete es: com.abc. def. Hay 2 archivos jar que contienen clases de este paquete, digamos jar1 y jar2, es decir, algunas clases están presentes en jar1 y otras en jar2. Estos archivos jar se firman usando el mismo almacén de claves pero en diferentes momentos en la compilación (es decir, por separado). Eso parece dar como resultado una firma diferente para los archivos en jar1 y jar2.
Puse todos los archivos en jar1 y los construí (y firmé) todos juntos. El problema desaparece
PD: Los nombres de los paquetes y los nombres de archivo JAR son sólo ejemplos
tuve una excepción similar:
java.lang.SecurityException: class "org.hamcrest.Matchers"'s signer information does not match signer information of other classes in the same package
La raíz del problema es que he incluido la biblioteca Hamcrest dos veces. Una vez que usaste el archivo Maven pom. Y también agregué la biblioteca JUnit 4 (que también contiene una biblioteca de Hamcrest) a la ruta de compilación del proyecto. Simplemente tuve que eliminar JUnit de la ruta de compilación y todo estaba bien.
Si agregó todas las jarras de bouncycastle.org (en mi caso de crypto-159.zip), simplemente elimine las de los JDK que no se aplican a usted. Hay redundancias. Probablemente solo necesites los frascos "jdk15on".
He usado el mismo certificado, pero ha expirado, ¿cómo volver a hacerlo? – Frank
¿Alguien puede explicarle a los novatos cómo hacerlo?Empecé a trabajar con Java y Spring hace una semana y estoy perdido. – mghz
Estoy enfrentando un problema similar, pero está en hibernate jarras. Estos frascos no están firmados, aún así me enfrento a este problema. ¿Por qué? Consulte http://stackoverflow.com/questions/24386463/java-lang-securityexception-signer-information-does-not-match-signer-informatio – user613114