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:

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:

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.

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

Perpetrado el 23 de septiembre de 2012 por una IN (Inteligencia Natural), la mia, con cierto esfuerzo.

Archivado en categoría(s) GNU/Linux, Internet, Software Libre