Hola
Sólo quería dejar constancia en el foro, por si alguien tiene el mismo
problema que yo, de que la solución de Ricardo ha funcionado perfectamente. He
compilado el applet con la versión de Maven 2.2.1, dejando el almacén de
certificados y el fichero de configuración dentro del
"uji-config-2.1.1-signed.jar", y con eso las rutas absolutas que usaba para
localizar los ficheros de los certificados ya no son necesarias. El applet
funciona perfectamente tanto bajo Windows como bajo Linux.
Muchas gracias por toda la ayuda recibida.
-----Mensaje original-----
De: "Ricardo Borillo Doménech" <[email protected]>
Enviado el 01/12/2011 11:59:59
Para: "Llista de correu per al CryptoApplet" <[email protected]>
Asunto: Re: [CryptoApplet] Cómo enlazar con certificados de una CA externa
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
_______________________________________________
CryptoApplet mailing list
[email protected]
http://llistes.uji.es/mailman/listinfo/cryptoapplet
