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
