Hola de nuevo, La solución buena es usar siempre alias y poner los certificados en el cas.keystore, como comentamos:
DIGIDOC_CA_CERT1=keystore://gva-root Como parece que si no está firmado el JAR, te da problemas, la mejor opción y más directa es bajarse el código del proyecto, modificar el keystore con los certificados que querais y volverlo a compilar con maven. El script de construcción de maven está preparado para firmar directamente todos y cada uno de los JARs generados, así que no hay que hacer nada especial. Os podeis bajar el código de aquí: http://universitatjaumei.jira.com/svn/CRYPTOAPPLET/tags/CryptoApplet_2.1.2/ Y podeis compilar desde donde está el fichero pom.xml principal así: mvn clean package 2011/12/1 ABINZANO MURILLO JOSE JAVIER <[email protected]>: > Hola de nuevo, Ricardo > > Esperaba no tener que molestaros de nuevo, porque en mi PC todo funciona > perfectamente, pero al pasar todo a un entorno de pruebas real me he vuelto > a encontrar con el problema de las rutas absolutas y la verdad es que estoy > algo desesperado, por estar bloqueado tan cerca de la solución. Intento > explicar el problema desde cero para que no haya que leer ningún correo > anterior > > 1.- Ahora mismo el applet funciona bien y está integrado con la aplicación > que lo va a usar. Para firmar en XAdES DigiDoc necesita los certificados de > la CA cliente, que se declaran en el archivo de configuración con una ruta > absoluta de este tipo (no encontré ninguna forma de hacerlo con rutas > relativas): > > DIGIDOC_CA_CERT1=C:\\PROYECTOS\\Gottax\\GottaX\\Aplicaciones\\Picos\\CryptoApplet\\SESCAM_Root_CA.cer > > 2.- Al configurar esa misma ruta para la máquina de pruebas, que es una > máquina Unix, intento definirlo así: > > DIGIDOC_CA_CERT1=\\\\opt\\opt\\apache-tomcat-6.0.26\\webapps\\picos.desa\\Aplicaciones\\Picos\\CryptoApplet\\SESCAM_Root_CA.cer > > Y el problema es que no hay manera de que el applet encuentre el certificado > con este tipo de ruta. ¿Puede ser porque necesite que las rutas absolutas > empiecen con una letra de unidad, como en Windows? ¿Habéis apuntado alguna > vez a certificados en una máquina Unix de esta manera? > > Hay otro camino para resolver el problema, que tú mismo me indicaste en > correos anteriores, y es utilizar los certificados desde una keystore, lo > que evitaría el problema de las rutas. Tengo la keystore del cliente, pero > si la meto en el jar de configuración del applet > (uji-config-2.1.1-signed.jar), el applet queda manipulado y se invalida su > propia firma, dándome el siguiente error al verificar la integridad: > > es.uji.security.crypto.timestamp.TokenVerifyException: Unable to decipher > pkcs#9 encoded attributes > at > es.uji.security.crypto.timestamp.TSResponseToken.verify(TSResponseToken.java:215) > at > es.uji.security.crypto.timestamp.TSResponseToken.verify(TSResponseToken.java:187) > at > es.uji.security.crypto.openxades.OpenXAdESSignatureFactory.formatSignature(OpenXAdESSignatureFactory.java:213) > at > es.uji.security.ui.applet.SignatureThread.run(SignatureThread.java:452) > > Probé, siguiendo tu sugerencia, a eliminar los ficheros "META-INF/UJI.SF" y > "META-INF/UJI.RSA" del jar firmado original, que en teoría era el único que > no necesitaba ir firmado, pero entonces el error es otro: > > ERROR thread-sig-0 es.uji.security.ui.applet.SignatureThread [08:18:05,695] > - <html><font color='red'>No se ha podido calcular la firma</font></html> > java.security.AccessControlException: access denied > (java.lang.RuntimePermission accessClassInPackage.sun.security.pkcs11) > at java.security.AccessControlContext.checkPermission(Unknown Source) > at java.security.AccessController.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPermission(Unknown Source) > at java.lang.SecurityManager.checkPackageAccess(Unknown Source) > at sun.plugin2.applet.Applet2SecurityManager.checkPackageAccess(Unknown > Source) > at java.lang.ClassLoader$1.run(Unknown Source) > at java.security.AccessController.doPrivileged(Native Method) > at java.lang.ClassLoader.checkPackageAccess(Unknown Source) > at > es.uji.security.crypto.openxades.OpenXAdESSignatureFactory.formatSignature(OpenXAdESSignatureFactory.java:86) > at > es.uji.security.ui.applet.SignatureThread.run(SignatureThread.java:452) > > La pregunta clave: si os proporciono la keystore.ca del cliente y mi fichero > de configuración, ¿podríais generarme un "uji-config-2.1.1-signed.jar", con > estos ficheros en su interior pero firmado por vosotros, a ver si así pasaba > estos controles de seguridad? Sé que es mucho pedir, pero es la única > solución que se me ocurre para evitar el problema de las rutas... > > Saludos y muchas gracias nuevamente: Javier Abínzano > _______________________________________________ > CryptoApplet mailing list > [email protected] > http://llistes.uji.es/mailman/listinfo/cryptoapplet > -- Salut, ==================================== Ricardo Borillo Domenech http://xml-utils.com / http://twitter.com/borillo _______________________________________________ CryptoApplet mailing list [email protected] http://llistes.uji.es/mailman/listinfo/cryptoapplet
