De acuerdo, muchas gracias una vez más.
Voy a hacer un último par de intentos con la idea de las rutas, por no
descartarlo sin habre probado todo, pero a partir de ahí investigo lo de maven
y sigo tu guía...
Saludos: Javier Abínzano
-----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
