Cómo instalar Firma Digital de Costa Rica en GNU/Linux Fedora 26

Esta guía documenta cómo instalar el controlador de la tarjeta de Firma Digital de Costa Rica y la jerarquía de certificados del Banco Central (SINPE) y del MICITT en el sistema operativo Fedora de arquitectura Intel de 64 bits (x86_64).

El motivo de esta nueva guía de instalación tenía los siguientes propósitos:

  • Configurar de la forma más sencilla y adecuada el sistema para que funcione con la mayor cantidad de programas.
  • Lograr que funcione para todos los usuarios del sistema, incluyendo los nuevos usuarios creados tras las instalación.
  • Funcionar con servicios obsoletos como el de la CCSS (con applet Java) en el navegador Icecat.

Instalación de las dependencias

  • Instalar el soporte CCID de PC/SC para que reconozca el lector de tarjetas y el plugin NPAPI IcedTea-Web para poder cargar el applet Java que permite firmar desde el navegador Icecat (Firefox ya no soporta applets Java) y OpenJFX si pretende instalarse el firmador del Banco Central:
# dnf -y install pcsc-lite-ccid icedtea-web icecat java-1.8.0-openjdk-openjfx

# systemctl enable --now pcscd.service

Descarga del “instalador”

  • Descargar el “instalador” en el desplegable llamado “Usuarios Linux” en la página de descarga de instaladores del sitio web de Soporte Firma Digital de Costa Rica, introduciendo el número de serie de la tarjeta y el captcha.

Desempaquetado del “instalador”

  • Descomprimir el archivo zip descargado con unzip, en el momento de escribir esta documentación se llama sfd_ClientesLinux_Rev08.zip. Se creará una carpeta llamada Firma Digital. Se asume que el archivo zip se ha descargado en la carpeta Descargas:
$ cd ~/Descargas

$ unzip sfd_ClientesLinux_Rev08.zip

Instalación de los certificados

Es necesario agregar a la lista de confianza la jerarquía de certificados del SINPE y del MICITT. Para ello, un par de comandos:

  • Copiar los certificados:
# cp ~/Descargas/Firma\ Digital/Certificados/* /usr/share/pki/ca-trust-source/anchors/
  • Regenerar los archivos de certificados para todas las aplicaciones:
# update-ca-trust

Instalación del módulo PKCS#11

Aunque hay un módulo en el directorio Librerías, no es la versión más reciente y tiene varios defectos de enlazado. La versión distribuida en el paquete PinTool es más reciente y funciona correctamente en todos los programas probados. En el siguiente proceso se extrae y se instala conservando la fecha original de la librería y con los permisos correctos de usuario y de SELinux.

  • Instalar el módulo PKCS#11 propietario en /usr/lib64/pkcs11:
$ cd ~/Descargas/Firma\ Digital/PinTool/IDProtect\ PINTool\ 6.41.01/RPM

$ rpm2cpio idprotectclient-641.01-0.x86_64.rpm | cpio -dim ./usr/lib/x64-athena/libASEP11.so
# mv usr/lib/x64-athena/libASEP11.so /usr/lib64/pkcs11/

# chown root:root /usr/lib64/pkcs11/libASEP11.so

# chmod 755 /usr/lib64/pkcs11/libASEP11.so

# chcon system_u:object_r:lib_t:s0 /usr/lib64/pkcs11/libASEP11.so
  • Crear los siguientes enlaces simbólicos (necesarios para que funcionen algunos programas y applets):
# ln -s /usr/lib64/pkcs11/libASEP11.so /usr/lib64/

# ln -s /usr/lib64/pkcs11/libASEP11.so /usr/lib/

# mkdir -p /usr/lib/x64-athena/

# ln -s /usr/lib64/pkcs11/libASEP11.so /usr/lib/x64-athena/
  • Si se va a trabajar con el applet de la CCSS se puede realizar el siguiente paso opcional:
# mkdir -p /Firma_Digital/LIBRERIAS/

# ln -s /usr/lib/libASEP11.so /Firma_Digital/LIBRERIAS/

# ln -s /usr/share/pki/ca-trust-source/anchors/ /Firma_Digital/CERTIFICADOS
  • Crear el fichero /etc/Athena/IDPClientDB.xml y abrirlo para edición:
# mkdir /etc/Athena/

# gedit /etc/Athena/IDPClientDB.xml
  • En la ventana del editor de textos gedit, pegar el siguiente texto, guardar y cerrar el editor:
<?xml version="1.0" encoding="utf-8" ?>
<IDProtect>
 <TokenLibs>
  <IDProtect>
   <Cards>
    <IDProtectXF>
     <ATR type='hexBinary'>3BDC00FF8091FE1FC38073C821106600000000000000</ATR>
     <ATRMask type='hexBinary'>FFFF00FFF0FFFFFFFFFFFFFFFFF0FF00000000000000</ATRMask>
    </IDProtectXF>
   </Cards>
  </IDProtect>
 </TokenLibs>
</IDProtect>
  • Crear un fichero llamado /etc/pkcs11/modules/firmadigital.module y abrirlo para edición:
# gedit /etc/pkcs11/modules/firmadigital.module
  • En la ventana del editor de textos gedit, pegar el siguiente texto, guardar y cerrar el editor:
module: libASEP11.so
  • Ejecutar el siguiente comando para reemplazar el enlace simbólico a libnssckbi para que haga uso de p11-kit-proxy de forma prioritaria:
# alternatives --install /usr/lib64/libnssckbi.so libnssckbi.so.x86_64 /usr/lib64/p11-kit-proxy.so 50

Eso es todo. Es necesario reiniciar Firefox, Evolution y cualquier otra aplicación que use certificados para que se apliquen los cambios. Si se ha insertado el lector y la tarjeta al lector, estas aplicaciones preguntarán por el PIN, lo que indicará que se la instalación ha sido exitosa.

Si el componente de firma del Banco Central está instalado debería funcionar para poder realizar la prueba de firma. El sitio web de Soporte Firma Digital podría usar todavía la prueba de Java y en este caso solamente funciona con el navegador Icecat. Icecat incluye varias extensiones que bloquean JavaScript y hay que desactivarlas para poder navegar en la mayoría de sitios y para poder firmar. En la página de prueba de firma con Java, si a la hora de firmar aparece en el navegador que se quiere ejecutar “IcedTea-Web”, hay que permitirlo. Si el navegador hace preguntas sobre el applet responder afirmativamente y aceptar a todos los cuadros de mensaje que aparezcan e ingresar el PIN cuando lo solicite.

Instaladores de Firma Digital de Costa Rica para GNU/Linux

Este proyecto de instaladores se ha creado en conjunto con Luis Zárate para facilitar la instalación de las herramientas necesarias de Firma Digital de Costa Rica en distribuciones GNU/Linux. Se trata de un desarrollo no oficial, creado voluntariamente para mejorar el soporte en diversas distribuciones este sistema operativo, inicialmente para Debian y Ubuntu y próximamente para Fedora, CentOS, openSUSE y Arch.

El mecanismo para instalar los instaladores se realiza mediante un repositorio. Esto permite facilitar la instalación de los paquetes y poder recibir actualizaciones de los mismos de la misma manera que el resto de software del sistema.

Los instaladores configuran el sistema para agregar confianza a los certificados de la jerarquía nacional en los diferentes programas que hacen uso de almacenes de certificados (NSS de Mozilla, OpenSSL, GnuTLS y Java), así como el controlador del lector de tarjetas y también el módulo para poder manejar la tarjeta de Firma Digital.

Basados en parte en las guías previas con diversas mejoras, se ha verificado que tras la instalación del paquete se pueden utilizar servicios de Firma Digital y se listan las autoridades de certificados de la jerarquía nacional en software como Mozilla Firefox, Mozilla Thunderbird, Chromium/Chrome, Evolution, Seahorse (contraseñas y claves) y aplicaciones Java.

Las instrucciones de instalación están disponibles en el sitio web repos.solvosoft.com.

Soluciones modernas para usar firma digital desde la web

En el mundo de los estándares web no ha habido ni hay (por ahora) un mecanismo que permita acceder a dispositivos de seguridad para poder firmar digitalmente. Mientras avanzan los esfuerzos en este sentido y con cierto retraso, en estos años han existido diversas formas no estándar para poder firmar, siendo todas ellas soluciones propietarias de cada navegador o bien utilizando tecnologías de complementos. Una de las más extendidas por su portabilidad era un firmador en Java utilizando applets, pero esta tecnología se está eliminando de los navegadores modernos y también siendo eliminada en futuras versiones de Java.

En la actualidad hay navegadores modernos como Edge que no disponen de ninguna forma de agregar complementos que permitan ejecutar código privilegiado y hasta la fecha no hay planes todavía para ello. Estos cambios fuerzan a utilizar formas más ingeniosas para resolver este problema de falta de interacción de sistemas de firma digital con los nuevos navegadores.

Afortunadamente existe una posible solución para comunicar sitios web con el hardware sin necesidad de complementos especiales en el navegador. La empresa que desarrolla y mantiene el proyecto DSS utiliza una técnica sencilla pero eficaz, mediante una aplicación de escritorio que ejecuta un servicio escuchando en un puerto en particular que tiene privilegios para acceder a los dispositivos de firma digital, los sitios web pueden comunicarse con este servicio local y enviarle la información que debe ser firmada y el resto del proceso se realiza en el lado de la web. Una de las aplicaciones existentes que utilizan esta técnica es software libre y se llama NexU, el cual se ha integrado en DSS a partir de la reciente versión 4.7.0, la cual ha decidido utlilizarla como reemplazo a los obsolescentes applets y JNLP.

Demostración de firma sin complementos de navegador

En el momento de escribir esto, he encontrado en línea una instalación de la WebApp de DSS 4.7 para poder probar NexU, que una vez descargado hay que ejecutar el jar que contiene el zip y recargar la página de la webapp, que detectará que se está ejecutando y el botón de formulario Install NexU cambiará a Submit. Para ejecutar el jar en GNU/Linux hay que tener instalado OpenJFX, que se explica en una entrada de blog previa. Para probarlo se puede desde una terminal mediante java -jar nexu.jar y manteniendo la terminal abierta. Para verificar que el servicio está ejecutándose correctamente se puede ingresar en el navegador en el sitio http://localhost:9776/nexu-info, donde debería aparecer un pequeño objeto JSON con la versión de la aplicación.

El problema del contenido mixto

El sitio web enlazado podría funcionar con HTTPS y el servicio local con HTTP, por lo que los navegadores modernos suelen bloquear esta comunicación. En Chromium aparece el icono de un escudo en la parte derecha de la barra de direcciones, donde haciendo clic se puede permitir la carga insegura y en Firefox aparece un candado verde con un triángulo gris con una exclamación, donde haciendo clic y a continuación en la parte derecha donde aparece un símbolo “>” se puede deshabilitar la carga insegura y finalmente el sitio web podrá acceder al servicio local.

A partir de las versiones 1.6.x de NexU se soporta HTTPS, una solución a este problema sería modificar la WebApp de DSS para que conecte a local por HTTPS y que exista un certificado para un host local, confiado e instalado en la máquina para que permita el acceso seguro a localhost y evitar el inconveniente del contenido mixto. La versión de NexU que sugiere DSS de momento es la 1.3, que no soporta HTTPS, por lo que debe descargarse la 1.6.2 o la 1.7 aparte y hacer los ajustes necesarios a DSS. En cualquier caso si bien la confianza SSL a localhost no se puede realizar con autoridades de certificación públicas, disponer de un nombre de host apuntando a 127.0.0.1 con una CA autofirmada, creada en la propia máquina, instalada y confiada y con ella firmando un certificado (para luego desechar la clave privada de la CA por seguridad) evita este problema. Otra opción sería usar un servidor seguro intermedio que se comunique con la aplicación de escritorio y el sitio web por backend, aunque esta opción también es relativamente compleja y requiere configuración a una dirección específica que haga conexión permanente desde la aplicación que accede a la tarjeta y mantener la comunicación abierta mientras esté el firmador en ejecución, pero esta solución requiere infraestructura adicional y la misma herramienta se alejaría de ser multipropósito sin previa actualización de la configuración.

Escenario ideal

Si bien esta solución es relativamente nueva y requiere algunos ajustes de configuración y previamente instalar la herramienta de acceso a la tarjeta, se perfila como una solución viable para poder realizar firma digital en la web de manera interoperable y multiplataforma. La posibilidad de que existieran actualizaciones a los instaladores de Firma Digital actuales del país contemplando la preinstalación de una herramienta de este estilo abriría la posibilidad de poder integrar esta solución en sistemas Windows, GNU/Linux y macOS y de que las instituciones adoptaran este mecanismo para solucionar el problema con los navegadores modernos.

Cómo firmar documentos PDF con firma digital de Costa Rica con software libre

La Política de Formatos Oficiales de los Documentos Electrónicos Firmados Digitalmente de Costa Rica especifica el tipo de documentos y su formato de firma digital. En el caso de PDF se utiliza un estándar especificado en Europa para firma digital avanzada (AdES) y en el caso de los PDF se llama PAdES. En el documento oficial enlazado previamente se muestra que tiene que soportar PAdES-LTV (permite la validación de forma longeva) y sugiere que se use el perfil Baseline. El asunto es que no hay mucho software libre en el mercado que permita la firma digital avanzada en PDF, sin embargo la propia Comisión Europea tiene un proyecto para ello (Digital Signature Services), que es un conjunto de librerías y herramientas en Java que permiten trabajar con firma digital con los estándares europeos, incluyendo soporte para PDF.

Hasta no hace mucho tiempo, una de las pocas implementaciones libres para trabajar con firma digital avanzada en PDF era iText, sin embargo este proyecto cambió de licencia y las condiciones de uso contradecían la propia licencia, además de presuntas incompatibilidades en contribuciones del código por parte de terceros que la hacían incompatible con la nueva licencia. Afortunadamente, el proyecto DSS (usando Apache PDFBox como alternativa a iText) permite firmar documentos PDF cumpliendo con la política de formatos oficiales nacional.

Instalación en GNU/Linux

Existe un firmador en formato independiente que funciona en el escritorio. Se puede descargar DSS standalone app package 5.1 (este es el más reciente en el momento de escribir esta entrada de blog).

Una vez descargado, descomprimir el archivo, contendrá dss-app.jar y un par de scripts para lanzar el jar de forma sencilla. El firmador que hay dentro del jar utiliza por defecto un servidor TSA europeo, para cambiarlo habrá que modificar un fichero que hay dentro del jar en la ruta spring/applicationContext.xml y buscar el texto: http://tsa.belgium.be/connect para reemplazarlo por el siguiente: http://tsa.sinpe.fi.cr/tsahttp/ y guardarlo modificado con este cambio dentro del archivo jar (un archivo jar es un archivo zip realmente).

Para poder ejecutar este jar en GNU/Linux se necesita el JRE de OpenJDK 8 y además OpenJFX 8 (JavaFX). En Fedora sudo dnf -y install java-1.8.0-openjdk-openjfx y en Ubuntu se puede instalar con sudo apt -y install openjfx.

Una vez instaladas las dependencias de Java, se puede ejecutar desde la terminal en la carpeta donde se haya descomprimido con sh dss-run.sh o bien con java -jar dss-app.jar.

Aparecerá una ventana como la siguiente:
Firmador DSS configurado

Firmado de un documento PDF

En fichero a firmar (File to sign) se selecciona el documento PDF que se desea firmar digitalmente.

En formato de firma (Signature format) se debe elegir PAdES porque se trata de un PDF.

En PAdES solamente existe el formato envuelto (Enveloped), por lo que este campo lo selecciona automáticamente.

En el nivel (Level) se elige el nivel de perfil de PAdES. PAdES-BASELINE-LTA es el equivalente a PAdES-LTV.

En algoritmo de resumen hash encriptado (Digest algorithm) se recomienda que sea como mínimo de tipo SHA-2, en la imagen de ejemplo se ha seleccionado SHA-512.

En Signature token API se tiene que seleccionar PKCS #11, entonces se desplegará PKCS #11 library donde hay que especificar dónde está la librería del módulo de Firma Digital (libASEP11.so).

En contraseña (Password) se ingresa el PIN de la tarjeta de Firma Digital.

Cuando se presione sobre Sign se iniciará el proceso de firmado y tras unos segundos aparecerá una ventana para guardar el PDF generado en la ubicación que se desee.

Eso es todo. El documento PDF ya tiene una firma válida en el país.

Demostración de documento válido generado

Esta imagen muestra que la firma generada es válida en la aplicación Acrobat Reader DC:

Validando firma en Adobe Reader

Existen formas de validar la firma del documento PDF con software libre (para no tener que usar Acrobat Reader DC como en este ejemplo), pero se explicará en próximas entradas de blog.

Aunque este firmador no tiene campo de estampa visible (“firma visible”), la política de documento oficial no indica que el documento requiera disponer este detalle visual en los PDF.

Cómo autenticarse en el Módulo de Firma Digital de la CCSS en GNU/Linux

El Módulo de Firma Digital de la Caja Costarricense de Seguro Social en la actualidad utiliza la tecnología Java mediante el (obsolescente) sistema de plug-ins NPAPI de navegador para autenticarse en el sitio y poder así acceder a diversos servicios en línea.

Este sitio tiene unos requerimientos particulares para los usuarios de sistemas operativos GNU/Linux que no resultan obvios sino más bien confusos. Si se ha instalado el sistema de Firma Digital de Costa Rica, esta página sigue sin funcionar y muestra un error con el mensaje:

Se ha generado un error en el certificado. Por favor verifique que la libreria PKCS11 se encuentra en la ruta: /usr/local/lib/libASEP11.so

Este mensaje no significa lo que aparenta: copiar la librería en esa ruta no servirá de nada, de hecho el applet no la lee de ahí, probablemente sea un mensaje que se usaba para código en desuso actualmente. Este mensaje de error realmente aparece porque no encuentra los certificados de la jerarquía de las autoridades certificadoras en una ruta del sistema específica.

Para solucionar este problema hay que crear los siguientes directorios en la raíz del sistema de ficheros:

sudo mkdir -p /Firma_Digital/CERTIFICADOS/

El applet java de la CCSS no lee datos del certstore (JKS) de Java, y en su lugar los lee de esa ruta específica en el caso de GNU/Linux y macOS, así que los certificados de la jerarquía CA hay que copiarlos allí solo para el uso de este applet en particular.

Asumiendo que se ha descargado el fichero instalador de la web de soportefirmadigital y se ha descomprimido el zip en la carpeta Descargas de nuestro usuario, para copiarlos allí sería:

sudo cp ~/Descargas/Firma\ Digital/Certificados/* /Firma_Digital/CERTIFICADOS/

Con este paso el applet ya no mostraría este error pero todavía no encontraría la librería. Hay que crear otra carpeta donde ubicar la librería:

sudo mkdir /Firma_Digital/LIBRERIAS/

Y la copiamos ahí o creamos un enlace simbólico desde otra que tengamos en otro lugar del sistema de ficheros. En este ejemplo se copiará de la que se descomprimió del zip de soportefirmadigital:

sudo cp ~/Descargas/Firma\ Digital/Librería/x64/libASEP11.so /Firma_Digital/LIBRERIAS/

Si se usa un GNU/Linux de 32 bit hay que cambiar el x64 anterior por x86 en la línea anterior.

Eso es todo. Ahora el applet de la página debería preguntar por el PIN y permitir seleccionar el certificado del usuario para poder autenticarse.

Autotools básico

Propósito

Crear paquetes de código fuente utilizando las herramientas de construcción de GNU (Autoconf, Automake y Libtool) a partir de uno o más ficheros de código fuente y los ficheros configure.ac y Makefile.am.

Esta guía muestra cómo a partir de un fichero fuente holamundo.c y el par de ficheros mencionados anteriormente se generará un archivo llamado holamundo-1.0.0.tar.gz que una vez desempaquetado se pueda compilar e instalar con el típico “./configure && make && sudo make install“.

En una próxima entrada se explicará cómo trabajar con dependencias (librerías).

Ventajas

  • Portabilidad, permite generar makefiles compatibles con diferentes implementaciones de Make, múltiples compiladores e intérpretes y generar scripts compatibles con múltiples shell.
  • Multiplataforma, los scripts generados facilitan las comprobaciones y configuraciones necesarias para generar una compilación cruzada, por ejemplo generar binarios para otra arquitectura agregando pocos parámetros.

Herramientas

  • autoconf, se encarga de generar el script configure a partir del fichero configure.ac.
  • automake, genera el fichero Makefile.in a partir del fichero Makefile.am.
  • libtool, gestiona la creación de librerías estáticas y dinámicas, y también la carga (en tiempo de ejecución) de librerías dinámicas.

Dentro del paquete autoconf hay otras herramientas relevantes como aclocal y autoheader. En este ejemplo básico se ejecutan de forma automática todas las herramientas mencionadas utilizando la herramienta autoreconf.

Herramientas relacionadas

  • make, procesa archivos Makefile. Existen varias implementaciones (GNU Make, BSD Make…) con algunas incompatibilidades que autotools solventa.
  • pkg-config, facilita información sobre la mayoría de las librerías instaladas en el sistema (ubicación, dependencias, versión, etc.).

¡Hola, Autotools!

Para crear el ejemplo básico de paquete es conveniente disponer de una carpeta de trabajo para tenerlo mejor organizado.

  • Crear una carpeta holamundo con una subcarpeta src para el código fuente y a continuación ubicarse en la carpeta de trabajo:
mkdir -p holamundo/src
cd holamundo

src/holamundo.c

  • Crear un fichero de código fuente C en src/holamundo.c:
#include <stdio.h>

int main() {
    printf("Hola Mundo!\n");

    return 0;
}

Makefile.am

  • Crear un fichero Makefile.am:
bin_PROGRAMS = holamundo
holamundo_SOURCES = src/holamundo.c

configure.ac

  • Ejecutar la herramienta autoscan en la carpeta de trabajo. Creará un fichero llamado configure.scan que hay que renombrar a configure.ac:
autoscan
mv configure.scan configure.ac

Nos habrá generado un fichero configure.ac parecido al siguiente:

#                                               -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

AC_PREREQ([2.69])
AC_INIT([FULL-PACKAGE-NAME], [VERSION], [BUG-REPORT-ADDRESS])
AC_CONFIG_SRCDIR([src/holamundo.c])
AC_CONFIG_HEADERS([config.h])

# Checks for programs.
AC_PROG_CC

# Checks for libraries.

# Checks for header files.

# Checks for typedefs, structures, and compiler characteristics.

# Checks for library functions.

AC_CONFIG_FILES([Makefile])
AC_OUTPUT
  • Modificar la macro AC_INIT del fichero configure.ac para mostrar el nombre del paquete, versión y dirección para avisar sobre errores (correo electrónico o web):
AC_INIT([holamundo], [1.0.0], [****@fran.cr])
  • Agregar la macro AM_INIT_AUTOMAKE en el fichero configure.ac para poder generar los Makefiles. Un buen lugar sería después de la línea de AC_CONFIG_HEADERS:
AM_INIT_AUTOMAKE([foreign subdir-objects])

Una vez modificado el fichero configure.ac debería ser parecido al siguiente:

#                                               -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

AC_PREREQ([2.69])
AC_INIT([holamundo], [1.0.0], [****@fran.cr])
AC_CONFIG_SRCDIR([src/holamundo.c])
AC_CONFIG_HEADERS([config.h])
AM_INIT_AUTOMAKE([foreign subdir-objects])

# Checks for programs.
AC_PROG_CC

# Checks for libraries.

# Checks for header files.

# Checks for typedefs, structures, and compiler characteristics.

# Checks for library functions.

AC_CONFIG_FILES([Makefile])
AC_OUTPUT

Generar configure y Makefile.in

  • Ejecutar:
autoreconf -i

Generar Makefile

./configure

Generar paquete (“tarball”)

make dist

Se habrá generado holamundo-1.0.0.tar.gz

Instalación genérica del paquete

  • Descomprimir:
tar xf holamundo-1.0.0.tar.gz
  • Entrar en la carpeta comprimida:
cd holamundo-1.0.0
  • Generar Makefile:
./configure
  • Construir:
make
  • Instalar:
sudo make install

Detalles de los ficheros creados

Makefile.am

bin_PROGRAMS indica la lista de programas (binarios en este caso) que va a crearse. En este caso se va a crear un binario llamado holamundo.

holamundo_SOURCES indica que nuestro holamundo tiene un listado de _SOURCES (ficheros fuente). En este ejemplo solamente hay uno (src/holamundo.c). Si el proyecto tuviera más ficheros de código fuente para crear el programa se separan con espacios. Si se desea poner un fichero por línea para hacer el mantenimiento de Makefile.am más limpio se puede utilizar \ al final de la línea para indicar que continúa en la siguiente, por lo tanto:

holamundo_SOURCES = \
    fichero1.c \
    fichero2.c \
    fichero3.c

es lo mismo que:

holamundo_SOURCES = fichero1.c fichero2.c fichero3.c

configure.ac

foreign indica que no se está creando un paquete GNU estándar (no exigirá la existencia de los ficheros ChangeLog, COPYING, NEWS y README para funcionar).

subdir-objects indica que se está usando el modo recursivo, es decir, no se van a usar múltiples ficheros Makefile.am para cada carpeta con objetivos a procesar.

AC_PREREQ indica la versión mínima de autoconf requerida para funcionar con el archivo de configuración.

AC_CONFIG_SRCDIR comprueba que el código fuente existe en la carpeta indicada mediante la comprobación de algún fichero fuente de la misma.

AC_CONFIG_HEADERS indica el nombre que tendrá el archivo de configuración de código fuente generado. Esto permite crear definiciones (por ejemplo, #define LOQUESEA 1) en el archivo indicado (por defecto, config.h) que podrá ser incluido en el código fuente. Estas definiciones podrían variar según lo que compruebe el script configure, resultando muy útil por ejemplo para verificar si el programa se ha compilado con o sin soporte de una característica en particular, por ejemplo para dependencias opcionales de librerías o comprobaciones de funcionalidad del compilador o de un sistema operativo en tiempo de compilación.

AC_PROG_CC comprueba la existencia de un compilador de C. Como autoscan ha detectado código fuente en C se ha agregado esta macro automáticamente.

AC_CONFIG_FILES recibe en el primer parámetro una lista de ficheros separados con espacios. (en este caso solo Makefile, que generará a partir de Makefile.in). Los ficheros con extensión .in se utilizan para sustituir los valores de las variables que contienen y generar el archivo de salida, normalmente con el mismo nombre sin el .in. Este proceso lo realiza la macro AC_OUTPUT.

Algunos parámetros del script configure

El parámetro --prefix permite indicar el directorio base de instalación, que por defecto suele ser /usr/local. Por ejemplo el programa holamundo se copiaría por defecto a la carpeta /usr/local/bin si no se cambia el --prefix. Las distribuciones suelen usar en sus paquetes --prefix=/usr. Si se quiere instalar un paquete y no se tienen permisos de superusuario se podría indicar una ruta dentro de la $HOME donde usualmente se suelen tener permisos de escritura.

./configure --help muestra información detallada de los parámetros.

Compilación cruzada con el script configure

El parámetro --host permite utilizar de forma sencilla toolchains para compilación cruzada, por ejemplo en una máquina Intel con Ubuntu e instalando el paquete gcc-arm-linux-gnueabihf proporciona el toolchain para ARMv7 (hard float) y puede realizarse esto:

./configure --host=arm-linux-gnueabihf
make

A continuación podemos verificar que el ejecutable holamundo es un ELF para arquitectura ARM y no para Intel mediante:

file holamundo

por lo que podremos comprobar que efectivamente se utilizaron las herramientas del toolchain sin tener que prefijar individualmente compilador, enlazador y demás ejecutables.

Cómo instalar Firma Digital de Costa Rica en GNU/Linux Ubuntu 16.04

Esta guía documenta cómo instalar el controlador de la tarjeta de Firma Digital de Costa Rica y la jerarquía de certificados del Banco Central (SINPE) y del MICITT en el sistema operativo Ubuntu 16.04 de arquitectura Intel de 64 bits (x86_64). Para otros sistemas operativos se documentará más adelante.

El motivo de esta nueva guía de instalación tenía los siguientes propósitos:

  • Configurar de la forma más sencilla y adecuada el sistema para que funcione con la mayor cantidad de programas.
  • Lograr que funcione para todos los usuarios del sistema, incluyendo los nuevos usuarios creados tras las instalación.
  • Superar la prueba de firma digital (con applet Java) en el sitio web de Soporte Firma Digital con el navegador Mozilla Firefox.

Instalación de las dependencias

  • Instalar el soporte CCID de PC/SC para que reconozca el lector de tarjetas y el plugin NPAPI IcedTea-Web para poder cargar el applet Java que permite firmar desde el navegador Firefox:
sudo apt -y install pcscd icedtea-plugin

Descarga del “instalador”

  • Descargar el “instalador” en el desplegable llamado “Usuarios Linux” en la página de descarga de instaladores del sitio web de Soporte Firma Digital de Costa Rica, introduciendo el número de serie de la tarjeta y el captcha.

Desempaquetado del “instalador”

  • Descomprimir el archivo zip descargado, en el momento de escribir esta documentación se llama sfd_ClientesLinux_Rev08.zip. Se creará una carpeta llamada Firma Digital. Se asume que se ha descomprimido dentro de la carpeta Descargas.

Instalación de los certificados

Es necesario agregar a la lista de confianza la jerarquía de certificados del SINPE y del MICITT. Para ello, un conjunto de comandos:

  • Copiar los certificados:
sudo cp Descargas/Firma\ Digital/Certificados/* /usr/local/share/ca-certificates/

sudo rename.ul .cer .crt /usr/local/share/ca-certificates/*.cer

for file in /usr/local/share/ca-certificates/*.crt; do sudo openssl x509 -inform DER -in "$file" -out "$file"; done 2>/dev/null
  • Regenerar los archivos de certificados para todas las aplicaciones:
sudo update-ca-certificates --fresh

Instalación del módulo PKCS#11

En Ubuntu todavía no existe una inciativa como la que existe en Fedora para solucionar el problema de unificación de NSS con Firefox, por lo que he considerado realizar un hack bastante intrusivo pero funcional para reemplazar las librerías NSS que resista a actualizaciones de Firefox, Thunderbird y NSS, siempre y cuando no haya cambios en la ubicación de las librerías, que es menos probable.

  • Copiar el módulo PKCS#11 propietario en /usr/lib/x86_64-linux-gnu/pkcs11/:
sudo cp Descargas/Firma\ Digital/Librería/x64/libASEP11.so /usr/lib/x86_64-linux-gnu/pkcs11/
  • Crear los siguientes enlaces simbólicos (necesarios para que funcionen algunos programas y applets):
sudo ln -s /usr/lib/x86_64-linux-gnu/pkcs11/libASEP11.so /usr/lib/x86_64-linux-gnu/

sudo ln -s /usr/lib/x86_64-linux-gnu/pkcs11/libASEP11.so /usr/lib/
  • Crear el fichero /etc/Athena/IDPClientDB.xml y abrirlo para edición:
sudo mkdir /etc/Athena/

sudo gedit /etc/Athena/IDPClientDB.xml
  • En la ventana del editor de textos gedit, pegar el siguiente texto, guardar y cerrar el editor:
<?xml version="1.0" encoding="utf-8" ?>
<IDProtect>
 <TokenLibs>
  <IDProtect>
   <Cards>
    <IDProtectXF>
     <ATR type='hexBinary'>3BDC00FF8091FE1FC38073C821106600000000000000</ATR>
     <ATRMask type='hexBinary'>FFFF00FFF0FFFFFFFFFFFFFFFFF0FF00000000000000</ATRMask>
    </IDProtectXF>
   </Cards>
  </IDProtect>
 </TokenLibs>
</IDProtect>
  • Crear un fichero llamado /etc/pkcs11/modules/firmadigital.module y abrirlo para edición:
sudo mkdir -p /etc/pkcs11/modules/

sudo gedit /etc/pkcs11/modules/firmadigital.module
  • En la ventana del editor de textos gedit, pegar el siguiente texto, guardar y cerrar el editor:
module: libASEP11.so
  • Crear un fichero llamado /usr/local/sbin/update-p11-kit-symlinks y abrirlo para edición:
sudo gedit /usr/local/sbin/update-p11-kit-symlinks
  • En la ventana del editor de textos gedit, pegar el siguiente texto, guardar y cerrar el editor:
#!/bin/sh

FIREFOX_LIB=/usr/lib/firefox/libnssckbi.so
THUNDERBIRD_LIB=/usr/lib/thunderbird/libnssckbi.so

if ! [ -L "$FIREFOX_LIB" ]
then
    echo "Firefox libnssckbi.so is not a symlink. Fixing..."
    mv -f "$FIREFOX_LIB" "$FIREFOX_LIB".bak
    ln -s /usr/lib/x86_64-linux-gnu/p11-kit-proxy.so "$FIREFOX_LIB"
fi

if ! [ -L "$THUNDERBIRD_LIB" ]
then
    echo "Thunderbird libnssckbi.so is not a symlink. Fixing..."
    mv -f "$THUNDERBIRD_LIB" "$THUNDERBIRD_LIB".bak
    ln -s /usr/lib/x86_64-linux-gnu/p11-kit-proxy.so "$THUNDERBIRD_LIB"
fi
  • Agregar el atributo de ejecutable al script:
sudo chmod +x /usr/local/sbin/update-p11-kit-symlinks
  • Crear un fichero llamado /etc/systemd/system/p11-kit-proxy-updater.service y abrirlo para edición:
sudo gedit /etc/systemd/system/p11-kit-proxy-updater.service 
  • En la ventana del editor de textos gedit, pegar el siguiente texto, guardar y cerrar el editor:
[Unit]
Description=mantenimiento de enlaces a p11-kit-proxy

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/update-p11-kit-symlinks

[Install]
WantedBy=multi-user.target

Activar el servicio al arranque y ejecutarlo una primera vez para comprobar que funciona:

sudo systemctl enable p11-kit-proxy-updater.service

sudo systemctl start p11-kit-proxy-updater.service

Eso es todo. Es necesario reiniciar Firefox, Thunderbird y cualquier otra aplicación que use certificados para que se apliquen los cambios. Si se ha insertado el lector y la tarjeta al lector, estas aplicaciones preguntarán por el PIN, lo que indicará que se la instalación ha sido exitosa.

En Firefox (hasta la versión 51 y la 52 ESR) ya se puede ir a realizar la prueba en el enlace “Verificación de Capacidad de Firma” del sitio web de Soporte Firma Digital de Costa Rica mencionado anteriormente y debería pasarla con éxito. En el navegador aparecerá que se quiere ejecutar “IcedTea-Web”, hay que permitirlo. Si el navegador hace preguntas sobre el applet responder afirmativamente y aceptar a todos los cuadros de mensaje que aparezcan e ingresar el PIN cuando lo solicite.

Cómo configurar Evolution para enviar correos electrónicos firmados digitalmente

Actualización: Seguir los pasos indicados en guías recientes para instalar firma digital que funciona para todos los usuarios. Una vez realizado ese paso, Evolution pedirá el PIN al acceder a las preferencias.

Evolution es la suite de trabajo en grupo del escritorio GNOME. Dispone de correo electrónico, contactos, calendario, tareas y notas, que se integran con las cuentas del sistema.

Para seleccionar un certificado, abrir Evolution y dirigirse a Editar -> Preferencias. Pedirá el PIN del dispositivo.

En la ventana Preferencias, seleccionar el certificado en el icono Cuentas de correo -> seleccionar la cuenta en uso -> Editar -> Seguridad -> MIME seguro (S/MIME) -> Certificado de firma -> Seleccionar

Si aparece ya se podrán firmar los mensajes digitalmente con validez legal en el país.

Se recomienda utilizar un algoritmo de firma SHA256 o superior.