Haciendo funcionar las Dirección Electrónica Habilitada del 060 en GNU/Linux

Actualización octubre 2013: Hay una nueva versión de la máquina virtual de libre descarga que te arregla esta locura del 060 y muchas cosas más

Actualización abril 2013: En esta otra entrada hay una máquina virtual linux para descarga con todo esto del 060 y varias cosas más solucionadas.

Ir por libre en la implementación de la Administración Electrónica es un error. Por no usar la plataforma @firma [1] e implementar su propio sistema de firma electrónica la DEH [2] es inutilizable.

Hay actualización [29 de octubre de 2012]

Que algún sistema de Administración Electrónica falle en GNU/Linux me fastidia, pero me sorprende que incluso no se pueda utilizar en Windows, debido a la falta de cuidado de los desarrolladores. Según mi averiguaciones (¡3 días!) he podido llegar a la conclusión de que los applets que emplean están intentando tirar del almacén de certificados de Java, en lugar de tirar del almacén de Firefox que me parece más lógico -solo tienes que poner el certificado en un sitio- y perfectamente posible con @firma. Intenté firmar en las siguientes plataformas con los siguientes resultados:

  • En Windows 7 con Firefox y Java de Oracle: el applet tardaba unos 4 minutos en cargar y finalmente terminaba fallando. Ningún mensaje útil de error o ayuda.
  • En Windows 7 con Internet Explorer y Java de Oracle: idéntico comportamiento.
  • En GNU/Linux con Firefox y OpenJDK + IcedTea plugin: curiosamente donde “mejor” funcionó porque pude acceder rápidamente, solo que no podía firmar. De nuevo ningún mensaje útil de error o depuración.

El problema me surgió cuando tenía que firmar el cambio de datos de mi domicilio, pero igualmente surge cuando quieres suscribirte a un nuevo procedimiento. La idea era que funcionara con OpenJDK pero finalmente tuvo que ser con Java de Oracle en un sistema virtualizado. No es la solución ideal, pero es la única que encontré de poder instalar correctamente mi certificado de usuario en el almacén de certificados de Java, que terminó siendo el mayor problema.

Una de las grandes ventajes de GNU/Linux es que los programas “gráficos” se pueden invocar desde la línea de comandos. Esto fue clave porque así tenía disponible toda la información de depuración del applet de firma y podía ir corrigiendo los problemas.

Depurando

Para ver porqué estaba fallando invoqué mi navegador desde consola:

abrowser

Utilizo aBrowser porque es la versión de Firefox que viene con Trisquel, pero todo funciona igual con un Firefox estándar. El primer intento de firma:

Intento de firma electrónica en el navegador
Primer intento de firma

hizo que aparecieran los siguientes mensajes en el terminal -he eliminado muchas líneas sin relación con el problema-:

180376 [Thread-3] INFO APE – Buscando certificado…
180377 [Thread-3] INFO KeyStoreUtils – loadPKCS11KeyStore(LINUX_32)
190277 [Thread-3] INFO KeyStoreUtils – PC/SC is not supported.
190277 [Thread-3] INFO KeyStoreUtils – Provider [SunPKCS11-dnie] not loaded.
190598 [Thread-3] INFO KeyStoreUtils – Error loading PKCS#11 [/cfg/dnie/linux.cfg]
190599 [Thread-3] INFO KeyStoreUtils – Due to [Initialization failed]
190599 [Thread-3] INFO KeyStoreUtils – Caused by [opensc-pkcs11.so: no se puede abrir el archivo del objeto compartido: No existe el archivo o el directorioopensc-pkcs11.so]
190599 [Thread-3] INFO KeyStoreUtils – loadOSKeyStore(LINUX_32)
190599 [Thread-3] INFO KeyStoreUtils – loadJVMKeyStore(LINUX_32)
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessor […]

Los mensajes que he destacado me estaban indicando que este applet intenta cargar las librerías PCKS#11 (librerías criptográficas) del sistema GNU/Linux en el que estamos. Es una dependencia que tenemos que resolver y me dije “vamos a ver si lo resolvemos con opensc”:

sudo apt-get install opensc

opensc (open Smart Card) es la librería que normalmente instalas cuando necesitas acceder a tarjetas criptográficas como el DNI electrónico. No es lo que queremos hacer ahora pero como el applet da ese fallo intenté solucionarlo así ¡y hubo suerte!. Vamos a ver qué pasa ahora -segundo intento de firma-:

180342 [Thread-4] INFO APE – Buscando certificado…
180343 [Thread-4] INFO KeyStoreUtils – loadPKCS11KeyStore(LINUX_32)
190232 [Thread-4] INFO KeyStoreUtils – PC/SC is not supported.
190232 [Thread-4] INFO KeyStoreUtils – Provider [SunPKCS11-dnie] not loaded.
205397 [Thread-4] INFO KeyStoreUtils – Unknown error.
205397 [Thread-4] INFO KeyStoreUtils – Due to [access denied (java.security.SecurityPermission insertProvider.SunPKCS11-DNIe)]
205415 [Thread-4] INFO KeyStoreUtils – loadOSKeyStore(LINUX_32)
205415 [Thread-4] INFO KeyStoreUtils – loadJVMKeyStore(LINUX_32)
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessor […]

Sigue fallando lo relacionado con el acceso a tarjetas criptográficas. La librería opensc hace de base, pero cuando estamos con el DNIe -que repito no es el caso- también instalamos pcscd, una librería que emula la interfaz Windows PC/SC (Personal Computer/Smart Card) que define la interfaz entre el ordenador y el lector de tarjetas. La librería pcscd es una implementación libre de este protocolo de comunicación:

sudo apt-get install pcscd

Resumiendo, opensc da acceso físico al lector y pcscd implementa los comandos de comunicación entre el ordenador y el lector. Vamos a ver qué pasa ahora:

180312 [Thread-3] INFO APE – Buscando certificado…
180312 [Thread-3] INFO KeyStoreUtils – loadPKCS11KeyStore(LINUX_32)
180493 [Thread-3] INFO KeyStoreUtils – loadOSKeyStore(LINUX_32)
180493 [Thread-3] INFO KeyStoreUtils – loadJVMKeyStore(LINUX_32)
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessor […]

Vamos bien porque ya no se queja de las librerías de acceso a lectores. De todas formas no se puede firmar. Pero ahora al menos es cuando da mensajes de error en el navegador explicando que no tiene acceso al certificado. Y uno piensa con toda lógica “si tengo instalado y funcionando el certificado en el navegador ¿porqué no accede a él?” Pues básicamente porque no le da la gana y por no usar @firma, un proyecto maduro y que funciona.

Pero entonces ¿donde va en busca del certificado? Pues resulta que busca en el almacén de certificados de Java. En sistemas Windows es fácil cargar el certificado mediante el Panel de Control de Java. En sistemas GNU/Linux con Java de Oracle también se puede hacer, pero después de mucho trastear no lo conseguí con la implementación OpenJDK. Así que empecé de cero con un Ubuntu 11.04 virtualizado en VirtualBox.

Una vez arrancado el sistema Ubuntu limpio lo primero que hice fue borrar todo rastro de Java. En Synaptic hay que buscar por “jre”, por “jdk” y por “icedtea” y desinstalarlo todo. Por ejemplo en la versión 11.04 con Java 6 hay que desinstalar:

  • openjdk-6-jre
  • openjdk-6-jre-headless
  • openjdk-6-jre-lib
  • icedtea6-plugin
  • icedtea6-netx
  • icedtea-6-plugin
  • icedtea-6-jre-cacao

Un buen síntoma de que Java ya no está instalado es que la orden

java

da error y que el complemento de Java no aparece en Firefox (teclear about:plugins en la URL).

Ahora hay que descargar Java para Linux para nuestra arquitectura. En lugar de descargar el paquete RPM instalable vamos a descargar el binario, entonces elegimos “Linux” o “Linux x64”. En mi caso elegí “Linux”. Cuando se descargó lo descomprimí en mi directorio inicial con:

tar xzf jre-7u7-linux-i586.tar.gz

Esto te crea un directorio llamado jre1.7.0_07. Así que tenemos Java disponible en /home/usuario/jre1.7.0_07 listo para ser usado. Dentro de ese directorio podemos ir al directorio bin y tratar de obtener la versión de java para ver que todo vaya bien. Si no dice nada de que no pudo crear la máquina virtual es que Java de Oracle funciona y no queda ni rastro de OpenJDK.

cd /home/usuario/jre1.7.0_07
cd bin
./java -version

Los siguientes pasos son decirle al sistema donde está Java e instalar el plugin para el navegador de forma manual. Lo primero se hace estableciendo la variable JAVA_HOME:

declare -x JAVA_HOME=”/home/usuario/jre1.7.0_07″

Para que el cambio sea permanente añadimos esa línea al final del archivo /home/usuario.bashrc. Como ya lo hemos hecho previamente en el terminal no es necesario cerrar y abrir la sesión. Todo habrá ido bien si ejecutamos el comando java desde cualquier directorio y funciona.

Ahora hay que instalar las librerías criptográficas (opensc y pcscd) como hice anteriormente cuando estaba con OpenJDK. También se emplearán ahora.

Firefox busca sus plugins en el directorio /usr/lib/firefox/plugins. No es la primera vez que hago esto y lo que había hecho siempre era un enlace simbólico en este mismo directorio tal que así:

cd /usr/lib/firefox/plugins
ln -s /home/usuario/jre1.7.0_07/plugin/i386/ns/libjavaplugin_oji.so

Y siempre funcionaba. Reiniciaba firefox y Java estaba funcionando. Pero esta vez no. Algo habrán cambiado en Java 7 y por un casual me encontré con que había que hacer este otro enlace simbólico en el mismo directorio:

ln -s /home/usuario/jre1.7.0_07/lib/i386/libnpjp2.so

Y por fin funcionó. Reinicié firefox y al ir a about:plugins tenía:

visor de firefox de plugins instalados
Visor de firefox de plugins instalados

Ahora que Java de Oracle está funcionando en firefox tenemos que instalar el certificado en el almacén de certificados de Java. ¿y como hago esto? Leyendo por aquí y por allá vi que Java traía un ejecutable muy interesante llamado ControlPanel.

cd $JAVA_HOME/bin
./ControlPanel

Una vez abierto hay que ir a la pestaña Seguridad y luego pulsar el botón Certificados. Aquí, habrá que añadir el certificado 3 veces. Una vez seleccionando primero el tipo “Certificados de Confianza”, otra seleccionando primero “CA de firmante” y una última como “Autenticación de cliente”. Se añadirá el mismo certificado las tres veces (en mi caso un archivo .p12). Si te pide una contraseña para el almacén de certificados escribir una y no olvidarla porque luego la usaremos para firmar

Y finalmente reiniciamos firefox y vamos a la página de la DEH [2]. Accedemos con el certificado (aquí se usa el que está en el navegador) y tratamos de modificar el perfil o suscribirnos a un procedimiento. Si todo ha ido bien y no se me ha olvidado ningún detalle en la explicación que también puede ser 🙂 conseguiremos firmar. Hay que recordar que pedirá la contraseña del almacén de certififcados de Java que le comunicamos anteriormente.

Petición de la contraseña y firma
Petición de la contraseña y firma

Actualización

La primera vez que intenté firmar en la DEH me apareció un diálogo con un mensaje cortado: “Es necesario habilitar”. Solo un tiempo después he sabido que estaba cortado, porque intenté el proceso de firma en un Windows XP y ¡pude ver el mensaje completo! (bien por ellos que no prueban en diferentes navegadores/sistemas). Resulta que hacía referencia a lo siguiente:

  1. Ir a about:config en firefox y prometerle que tendrás cuidado.
  2. Escribir “signed” en Filtro
  3. Hacer doble click en la clave signed.applets.codebase_principal_support. Esto hace que su valor cambie a true y parece que es lo que finalmente permite otorgar confianza a las applets para que puedan firmar (esto es lo que yo interpreto).

Referencias:

  1. Plataforma de Validación Electrónica @firma (wikipedia)
  2. Dirección Electrónica Habilitada

17 thoughts on “Haciendo funcionar las Dirección Electrónica Habilitada del 060 en GNU/Linux

  1. Lo de la administración electrónica, joder, no tiene nombre.

    Por cierto, que hace tiempo que no se de la evolución de @firma. Mi experiencia como usuario de servicio ha sido mala.

    Saludos.

  2. Que yo sepa @firma va muy bien. Hace poco lo he utilizado, creo que con la Dirección Electrónica Vial. Si esta gente de la DEH hubieran incorporado @firma el servicio no sería tan malo.
    Un saludo.

  3. Pues yo no tengo suerte. Estoy tratando de modificar mis suscripciones y nada de nada.

    Recibí una carta de la AEAT diciéndome que iban a pasar sus notificaciones a .060.es

    He instalado la última versión de java 1.7.0_17 he instalado el certificado en el navegador (Firefox, ya lo estaba) y en la máquina java ejectuando $RUTA/jre-1.7.0_17/bin/jcontrol he leído estas instrucciones y otras. Y nada de nada. Siempre el mismo mensaje:

    “No se pudo hallar el certificado. En sistemas operativos Unix es necesario que éste se encuentre instalado en la máquina virtual de Java. Por favor, revise que no sólo tiene instalado el certificado en el navegador.”

    He comprobado el about:config. He redireccionado el archivo /usr/bin/java de forma que se ejectua la última versión. Para ello he modificado los enlaces simbólicos correspondientes.

    Y nada de nada.

    ¿Alguna pista sobre cómo seguir?

  4. Otra opción para seguir es probar con la misma versión exactamente que yo he empleado, que es la jre1.7.0_07.
    El sistema de @firma es un poco exigente y llega al extremo de requerir una revisión concreta de una versión concreta de la jre, en este caso la revisión 07 de la versión 1.7.0 a mi me ha funcionado bien. Prueba por ahí.
    El /usr/bin/java no tiene nada que ver con la versión de Java que esté invocando el navegador. Al firefox lo único que le interesa es el enlace simbólico hacia la librería libnpjp2.so de la que hablo en la entrada.
    No entiendo como en un servicio tan importante se ha montado una chapuza tan enorme. Espero que tengas suerte y si necesitas más indicaciones escríbeme.

  5. basura infecta es lo que es

    también había cambiado el redirecionamiento del libnpjp.2.so en los plugins de firefox. Ninguno de las dos versiones que tengo la jre.1.7.0 y la jre-1.7.0u17 funcionó.

    No encuentro la jre.1.7.0_07 para bajarla y probar.

  6. Gracias,

    ya la he bajado. Y nada de nada. Igual.

    Aparte de instalar el java 1.7.0_07 he cambiado el direccionamiento en .mozilla/plugins de forma que libnpnjp2.so apunte a la vesión 1.7.0_07.

    ¿Habría que hacer algo más?

  7. Hola,

    he perdido toda una mañana para poder firmar con java. Gracias a tu manual al final lo he conseguido.
    Sólo añadir que lo he hecho con chrome lanzandolo con la opción “–allow-outdated-plugins”. Salud!

  8. Para empezar, pido disculpas por el comentario fuera de fecha.

    Muy currado el problema y la solución. Yo estoy experimentando esto mismo en un cliente, con Windows 7 e Internet Explorer (he probado con Chrome, pero no le he dedicado mucho tiempo).
    La putada de Windows es la falta de herramientas, o mi desconocimiento de ellas, para obtener trazas y registros de logs.
    Afortunadamente he podido sacar de la propia consola de Java el error que me da (porque sólo tengo el fallo en la DEH y sólo al firmar), y parece ser que los tiros van por el lado de lo del lector de DNIe que comentas.
    En concreto tengo estos errores:
    20120 [Applet 1 LiveConnect Worker Thread] INFO KeyStoreUtils – loadPKCS11KeyStore(WINDOWS_7_32)
    20215 [Applet 1 LiveConnect Worker Thread] INFO KeyStoreUtils – PC/SC is not supported.
    20215 [Applet 1 LiveConnect Worker Thread] INFO KeyStoreUtils – Provider [SunPKCS11-dnie] not loaded.
    20275 [Applet 1 LiveConnect Worker Thread] INFO KeyStoreUtils – Error loading PKCS#11 [/cfg/dnie/windows.cfg]
    20275 [Applet 1 LiveConnect Worker Thread] INFO KeyStoreUtils – Due to [Error parsing configuration]
    20275 [Applet 1 LiveConnect Worker Thread] INFO KeyStoreUtils – Caused by [Absolute path required for library value: UsrPkcs11.dll]
    20275 [Applet 1 LiveConnect Worker Thread] INFO KeyStoreUtils – loadOSKeyStore(WINDOWS_7_32)

    Y luego, este fallo:
    21220 [Applet 1 LiveConnect Worker Thread] INFO APE – signXADES()
    21220 [Applet 1 LiveConnect Worker Thread] INFO APE – Encoding [UTF-8]
    21220 [Applet 1 LiveConnect Worker Thread] INFO APE – Recuperando datos a firmar
    21235 [Applet 1 LiveConnect Worker Thread] INFO APE – Obteniendo clave privada de [CN= – CIF – NOMBRE – NIF , OU=, OU=FNMT Clase 2 CA, O=FNMT, C=ES]
    21235 [Applet 1 LiveConnect Worker Thread] INFO APE – Recuperada clave privada
    25785 [Applet 1 LiveConnect Worker Thread] INFO APE – Ocurrio un error al realizar la firma XADES.
    25785 [Applet 1 LiveConnect Worker Thread] INFO APE – Due to [javax.xml.crypto.URIReferenceException: com.sun.org.apache.xml.internal.security.utils.resolver.ResourceResolverException: Cannot resolve element with ID UsuarioFinalSignature-XADES-Properties]
    25785 [Applet 1 LiveConnect Worker Thread] INFO APE – Caused by [com.sun.org.apache.xml.internal.security.utils.resolver.ResourceResolverException: Cannot resolve element with ID UsuarioFinalSignature-XADES-Properties]
    25785 [Applet 1 LiveConnect Worker Thread] INFO APE – Caused by [Cannot resolve element with ID UsuarioFinalSignature-XADES-Properties]
    25785 [Applet 1 LiveConnect Worker Thread] INFO APE – showError(applet.error.sign.exception)

    Esta tarde probaré por donde comentas en tu artículo, a ver si soluciono el entuerto.

  9. Gracias. Me estaba volviendo loco para poder activar el DEH. ¿Por qué se complican (y nos complican) tanto la vida los desarrolladores de las Administraciones Públicas?
    Cuanto más sencillos los procedimientos, más sencillo de usar y administrar.

  10. Hola,

    Buen manual, lo han hecho un poco complicado los de DEH (correos), al igual que el DNIe… será la misma subcontrata? jejej

    Por cierto, voy siguiendo los pasos y todo coincide, pero no encuentro el botón de certificados al lanzar ./ControlPanel (en $HOME/java/bin)

    Se debe arrancar como root ese binario? o algo me he perdido?

    Un saludo

  11. Para todos los que tengáis problemas a la hora de firmar un certificado, por que al seleccionar el certificado a la hora de firmar no aparezca o aparezca uno caducado y en el panel de control de java no aparece el botón de certificados, podéis hacerlo de forma manual (probado en ubuntu 12.04):

    1. Importar al almacen
    $ keytool -importkeystore -srckeystore micertificado-fnmt.p12 -srcstoretype pkcs12 -destkeystore ~/.java/deployment/security/trusted.clientcerts

    Si lo hizo bien, te aparecerá:

    Comando de importación completado: 1 entradas importadas correctamente, 0 entradas incorrectas o canceladas

    Si ese fichero estuviese corrupto u os diese otro tipo de problemas, podéis borrarlo y al importar el nuevo certificado lo creará de nuevo.

    1. Con Ubuntu 14.04 no aparece el botón de certificados en el panel de control de Java, al menos con Oracle Java.

      He seguido las instrucciones de Antonio Beamud Montero y he conseguido añadir mi certificado al almacén de Java, y firmar la DEH del 060.

      ¡Vaya chapuza de las administraciones públicas!

      Muchas gracias compañer@s!

  12. Hola
    Ayer estuve volviéndome loco más de 14 horas intentando resolver el inscribir a mi señora esposa al famoso “notificaciones.060”, pero firmando con el DNIe. ( no he dicho que con Debian, Java 8, y Firefox 33, creo.Y al final llego al famoso punto en que me dice que seleccione un certificado del almacén de Java. Que no lo tiene. El problema es que cuando usas el DNIe, puedes acceder el certificado del DNI desde Firefox, pero desde Java no, y cuando es el propio DNI el Almacén del certificado, no es exportable desde el navegador hacia Java.
    Sigo buscando solución, aunque me parece que ésta va a ser el obtener un certificado en forma de ficherito de la FNMT, que pueda exportar de Firefox a Java.
    Se os ocurre algo ?
    Un saludo.

    Alberto.

Responder

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *