Parece que fue ayer cuando la FMNT-RCM solicitó la inclusión de su certificado raiz en el sistema de distribución de certificados raiz de CA CA/Browser Forum de su oficial autoridad de certificación (CA en inglés) en España CERES. Bueno, en realidad no fue ayer, fue el 26 de mayo de 2008:

pero lo que sí fue ayer 25 de enero de 2017, es la resolución exitosa del procedimiento:

Sólo ha tomado 3167 días para una de las instuciones más importantes de España y uno de los proyectos de migración a la economía digital más importantes del país que ha sido la obligada, y convengo que necesaria, adopción de las prácticas de comunicaciones digitales seguras al menos en la relación con las administraciones del estado. Pero para el usuario la experencia ha sido con frecuencia frustrante y el que más y el que menos hemos padecido problemas: desde la no inclusión de serie en el software que usamos del certificado raiz a las endiabladas configuraciones de los servicios de cada administración que con frecuencia hacían incompatible una configuración de tu navegador entre ellas. Y todo ello sin contar con la peor experiencia aún que ha sido la de la adopción del DNIe. Personalmente hace tiempo que renuncié a usar el DNIe.

¿Tan difícil era hacerlo antes? Estoy convencido de que se trata de un proceso muy riguroso pero, diablos, estamos hablando de la Real Casa de la Moneda, no de cualquier departamento escondido. Estamos hablando del certificado raiz que, en teoría, debería usar la Agencia Tributaria, que podemos concluir que como recaudador tiene las más imperiosas necesidades en mantener el mejor, más accesible y económico portal electrónico con el ciudadano aunque sólo sea para el mayor beneficio de las arcas del estado. Tanto es así que para ser más operativo la Agencia Tributaria a partir de cierto momento adoptó los certificados emitidos por Camerfirma, que si bien son reconocidos por el estado son gestionados por el Consejo Superior de Cámaras de Comercio que entiendo es una entidad semi privada.

Por muy prestigiosa y loable entiendo que Camerfirma no es una organización completamente estatal y en mi opinión, aparte de la apreciación estética por la incongruencia, es el epítome de los problemas del desarrollo e implantación de la administración electrónica en España, a pesar de los recursos aportados y el esfuerzo bienintencionado de los funcionarios que han puesto todo su corazón en un avance tan importante.

Aunque tampoco todo el monte es orégano, como puede apreciarse en el certifcado usado en la Aplicación Web Prestadores de Servicios de Certificación:

En fin, bueno es si bien acaba, que 3167 días no son nada.

Las comparaciones son odiosas

Y bueno, sí yo también, como diría República Gorila sí que estoy un poquito lleno de odio y sí, podemos intentar comparar la duración de diferentes procedimientos de admisión a través del servicio Bugzilla de Mozilla:

Y por brevedad sólo elegiremos algunas firmas reconocidas oficialmente en España:

Camerfirma

• Entrada 562395
• registro: 2010-04-28
• resolución: 2010-12-02
• duración: 219 días

Agencia de Tecnología y Certificación Electrónica

• Entrada 653761
• registro: 2011-04-29
• resolución: 2011-07-31
• duración: 94 días

Consorci AOC (CAtCert)

• Entrada 707995
• registro: 2011-12-06
• resolución: 2012-01-17
• duración: 43 días

EDICOM

• Entrada 550521
• registro: 2010-03-05
• resolución: 2010-03-29
• duración: 130 días

En fin. La lista no es exhaustiva aunque me ha parecido comprobar que hay varias AC reconocidas que o no han pasado por el proceso o sencillamente siquiera lo han solicitado. En cualquier caso felicitamos al campeón de nuestra somera investigación, el equipo de CATCert que ha sido capaz de resolver en 43 días lo que a nuestra referente FNMT ha tomado, insistimos, 3167 días.

Otros asuntos en el tintero

Me quedo sin más tiempo para extenderme como quisiera verificando el estado de las siguientes cuestiones pendientes:

• ¿Está reconfigurado por fin el servicio de renovación de los certificados FNMT para que pueda usar, por ejemplo, las versiones recientes de navegadores (observemos que la primera versión de Firefox que incorpora de serie el certificado es la 53.0a). Personalmente hace unos meses me encontré con la imposibilidad de poder renovar mi certificado usando una configuración que desactive cosas como el inseguro protocolo SSL3, práctica habitual en cualquier navegador moderno.
• El servicio OCSP de Ceres, ¿está por fin públicamente accesible sin pagos?

Convocatoria

Pero alegremos los corazones. Desde mi modesta tribuna convoco a todos los españoles a celebrar este pequeño paso para la humanidad pero un paso de gigante para Ceres-FMNT brindando por tan feliz suceso:

PS: Sergio de los Santos parece que profundizó mucho más en los progresos técnicos del proceso de aprobación en la increíble historia de Firefox y el certificado raíz de la FNMT.

He decidido, por fin, crear mi propio servicio VPN. Los motivos principales son poder asegurar navegación privada y cercionarme que uso un servicio de confianza 100% auditado… por mi.

Requisitos

• servicio OpenVPN
• usando docker
• servidor Centos 7
• reutilizando alguna configuración existente
• pero sin reutilizar imágenes publicadas en el Docker Hub, por celo en la seguridad
• poder conectar desde máquinas Linux y teléfonos Android

La configuración elegida es una creada por Kyle Manna: https://github.com/kylemanna/docker-openvpn/ ¡Gracias Kyle!

Procedimiento de instalación y configuración del servidor

En este caso usamos CentOS 7, pero como no está disponible docker-compose he tenido que retro-portarlo y lo tenéis disponible en un repositorio específico.

Preparación:

cd /etc/yum.repos.d ; wget https://copr.fedorainfracloud.org/coprs/olea/docker-compose/repo/epel-7/olea-docker-compose-epel-7.repo
yum install -y docker docker-compose
yum install -y docker-lvm-plugin.x86_64 docker-latest.x86_64
yum upgrade -y
groupadd docker
usermod -G docker -a USUARIO
echo "VG=sys" > /etc/sysconfig/docker-storage-setup
docker-storage-setup
systemctl enable docker
systemctl start docker

Si docker ha podido arrancar entonces probablemente está listo para empezar a trabajar.

Obviamente también hay que configurar el DNS del servicio VPN.MISERVIDOR.COM en el servidor correspondiente.

Entrando en materia:

mkdir servicio-VPN.MISERVIDOR.COM
cd servicio-VPN.MISERVIDOR.COM
git clone https://github.com/kylemanna/docker-openvpn
cat <<EOF > docker-compose.yml
version: '2'
services:
    openvpn:
        build:
            context: docker-openvpn/
        cap_add:
            - NET_ADMIN
        image: Mi-ID/openvpn
        ports:
            - "1194:1194/udp"
        restart: always
        volumes:
            - ./openvpn/conf:/etc/openvpn
EOF

Y continuando con las instrucciones indicadas:

• construimos localmente la imagen docker desde cero de una sola vez:

docker-compose run --rm openvpn ovpn_genconfig -u udp://VPN.MISERVIDOR.COM

• iniciamos la AC local propia (se nos pedirá la contraseña de la clave privada):

docker-compose run --rm openvpn ovpn_initpki

• finalmente lanzamos el contenedor:

docker-compose up -d openvpn

Procedimiento de altas de usuarios

• Alta del usuario:

docker-compose run --rm openvpn easyrsa build-client-full USUARIO nopass

• generación de la configuración local de OpenVPN para el mismo usuario:

docker-compose run --rm openvpn ovpn_getclient USUARIO > USUARIO.ovpn

• Este fichero lo copiaremos a nuestra máquina porque es el que nos habilitará el acceso VPN.

Problema importando configuraciones de OpenVPN y NetworkManager

Personalmente me he encontrado el problema varias veces de que el GUI de configuración de NetworkManager no es capaz de importar los certificados criptográficos al configurar una conexión VPN importando ficheros ovpn. Tras investigarlo varias veces he concluido que se debe a un bug documentado que en mi caso no está resuelto en NetworkManager-openvpn-gnome-1.0.8-2.fc23 pero sí en NetworkManager-openvpn-gnome-1.2.4-2.fc24.

Si aún os encontráis con ese problema habría dos alternativas: o actualizar a una versión reciente de NM o conectarse manualmente desde el CLI:

sudo /usr/sbin/openvpn --config USUARIO.ovpn

El 24 de noviembre he sido invitado a charlar para hablar de la experiencia de HackLab Almería en un evento en Antequera organizado por IBM. He aprovechado para seguir trabajando en el material retrospectiva del HackLab Almería que preparé para el GDG Spain Summit y lo he adaptado a formato de transparencias con mi agradecido Slidy.

Las transparencias están disponibles en http://olea.org/conferencias/doc-conf-20161124-Encuentro-IBM/

Además voy a tener la oportunidad de volver a impartir la conferencia en un par más de ocasiones así que creo que refinaré más aún este material, que también me sirve para profundizar la retrospectiva de los dos años largos que he dedicado a «la movida HackLab Almería».

Gracias a Haroldo Díaz Armas por la invitación, a Elisa Martín Garijo por sugerir mi persona y a Javier Bentabol por su entusiasmo con nosotros.