Gestionando nuestros certificados digitales con XCA

La gestión de claves y certificados criptográficos es una tarea que todo administrador de sistemas debe realizar con especial cuidado ya que su mala gestión podría llegar a comprometer por completo la seguridad de toda nuestra infraestructura. XCA es una magnífica herramienta que nos ayudará en esta tarea, proporcionándonos una interfaz gráfica sencilla, amigable y potente…​ todo ello sin requerir de ninguna instalación o configuración compleja, ¿alguien da más?.

En este artículo analizaremos la aplicación, qué nos permite hacer y dos posibles casos de uso en los que podremos ver parte de su potencia en acción.

El motivo por el que empiezo el blog describiendo esta herramienta es porque será la que usaremos para generar todos los certificados de los servicios que se irán tratando en la sección de "Recetas de configuración".

1. ¿Qué es XCA?

Como ya he comentado, se trata de una utilidad para la gestión de claves y certificados criptográficos que nos permitirá, entre otras cosas, gestionar nuestra propia Infraestructura de Clave Pública o PKI de manera sencilla. Es una aplicación gráfica de escritorio portada a las principales plataformas (Windows, MacOS, GNU/Linux), escrita en C++, que hace uso de las librerías OpenSSL para todas las funciones criptográficas y de las librerías Qt5 para todo lo demás. Podríamos considerar a XCA como un frontend gráfico de OpenSSL, al menos de las utilidades de gestión y emisión de certificados.

La última versión disponible de XCA es de Octubre del 2015 y coincide con la que encontramos empaquetada en Ubuntu 16.04LTS. Desde entonces no hay actividad en las fuentes, puede verse que el autor ha ido publicando algún parche posterior en el foro pero no las ha subido al repositorio.

Para instalar XCA en Ubuntu 16.04 bastará con hacer un simple:

$ sudo apt-get install xca

2. ¿Qué nos proporciona XCA?

A continuación enumeraré las características más sobresalientes que encuentro en esta herramienta.

2.1. Bases de datos individuales

XCA trabaja con su propio formato de fichero al que llama "base de datos" y en el que almacena toda la información: claves públicas y privadas, certificados, lista de certificados revocados, opciones, etc. Todo esto lo hace de manera segura, cifrando dentro del mismo fichero todas las claves privadas con 3DES mediante una clave que paso que deberemos introducir cada vez que abramos una base de datos en la aplicación.

Creando una base de datos en XCA
Figura 1. Creando una base de datos en XCA

Esta opción de almacenar en ficheros es muy interesante. Por un lado está la sencillez de tener las bases de datos cifradas en ficheros independientes, evitando la necesidad de un sistema gestor de base de datos aparte y permitiéndonos incluso almacenar estos ficheros en tokens cifrados junto con la aplicación compilada estáticamente. Por otro lado, disponer de diferentes bases de datos (y en diferentes lugares físicos) nos dará "mucho juego", ya que nos permitirá tener separadas infraestructuras de clave pública diferentes, tener entidades certificadoras offline, crear entidades certificadoras subordinadas y delegarlas…​

2.2. Gestión de claves

XCA nos permite generar, almacenar, importar y exportar claves criptográficas. Todas estas acciones se realizan de forma muy sencilla sin la necesidad de tener que recordar complejos parámetros de la utilidad openssl.

En lo que respecta al proceso de generación de claves, XCA nos permite generar claves RSA, DSA y de Curvas Elípticas, permitiéndonos seleccionar además opciones específicas de cada tipo. Una vez que hayamos generado el par de claves, ya estarán disponibles para asociarlas a los nuevos certificados X.509 que creemos.

Además de generar claves, podremos almacenar en nuestra base de datos las ya que tengamos en otros formatos, ya sea PEM, DER, PKCS#8, SSH2 o incluso desde un PKCS#12 (el que suele usarse en entornos Microsoft).

Finalmente, otra funcionalidad que no podía faltar en la aplicación es la exportación de las claves ya sea la clave pública, la privada o ambas en diferentes formatos: PEM, DER, PKCS#8 y SSH2.

Exportando claves en XCA
Figura 2. Exportando claves en XCA

2.3. Gestión de certificados y solicitudes de firma

XCA soporta el estándar X.509 y nos permitirá desde crear nuestras propias solicitudes de certificados para que una entidad certificadora nos las firme y almacenar la información de nuestros certificados, hasta crear nuestra propia PKI (Infraestructura de Clave Pública) con la que crear y firmar los certificados de nuestros servidores, usuarios y dispositivos.

Todo esto lo realizaremos de forma gráfica y sencilla, sin necesidad de tener que recordar complejos parámetros de openssl y sin renunciar por ello a su potencia. La aplicación nos permitirá escoger:

  • el origen de la firma: si se trata de una solicitud, si el certificado será autofirmado o si lo firmará una CA de nuestra base de datos.

  • el algoritmo de firma: MD5, SHA1, SHA2 y RIPEMED160.

  • los atributos del asunto del certificado junto al par de claves de nuestro repositorio

  • extensiones básicas del certificado, periodo de validez (si firmamos nosotros)

  • información de revocación de la CA firmante y otras extensiones como nombres alternativos (para su uso en múltiples dominios)

  • extensiones del uso de la clave

  • un apartado de opciones avanzadas en el que se nos permite introducir directamente opciones de configuración de OpenSSL que no están en la GUI.

Configurando extensiones de un certificado en XCA
Figura 3. Configurando extensiones de un certificado en XCA

2.4. Gestión de smartcards y tokens criptográficos

XCA también soporta la gestión de claves y certificados de tarjetas y tokens que soporten el estándar PKCS#11.

Esto personalmente no he llegado a utilizarlo por lo que poco puedo aportar más que el enlace a la documentación.

2.5. Gestión de plantillas de certificados

Una de las opciones más potentes de XCA es la creación de plantillas de certificados. Esto nos permitirá realizar plantillas para los distintos tipos de certificado que podamos necesitar: servidor web, firma y cifrado de correo electrónico, usuario vpn, ipsec, etc. Lo que simplificará enormemente la creación de los mismos al no tener que recordar qué parámetros son los adecuados al mismo tiempo que evitará cometamos errores.

2.6. Gestión de listas de revocación

Uno de los temas más controvertidos de una PKI es la revocación de certificados, que comprende el proceso de revocar los certificados que hayan podido ser comprometidos y la publicación actualizada de esta información. Esto hay que tenerlo muy en cuenta a la hora de diseñar, desplegar y gestionar una PKI. En lo que respecta a XCA, la utilidad nos permite revocar certificados y generar listas de revocación CRL para su posterior publicación, todo ello con un par de clicks.

3. Posibles casos de uso

El propósito de este artículo simplemente es presentar y darte unas nociones básicas de cómo se usa esta potente herramienta. Entender los conceptos básicos de cómo funciona y cómo se gestiona una PKI sería un tema que requeriría de una serie completa de artículos. Por ello únicamente voy a presentar dos sencillos casos de uso que pueden ayudarte, sin profundizar en los detalles de lo que hay detrás.

3.1. XCA como almacén de nuestros certificados web

Supongamos somos responsables de la gestión de los servidores web y de correo de múltiples clientes y queremos tener todos los certificados y claves almacenados en un único lugar y de manera segura. En este caso, podremos usar XCA en el proceso de petición de firma, almacenamiento y exportación de certificados para desplegar en los servidores.

3.1.1. Generando nuestra petición de certificado

  1. En primer lugar deberemos crear una base de datos, para ello nos iremos a File → New Database y crearemos nuestra base de datos en el lugar y con el nombre que deseemos e introduciremos una contraseña (que no olvidaremos ya que de lo contrario no podremos acceder a las claves públicas).

  2. A continuación recomiendo ir a File → Options y cambiar el algoritmo de firma por defecto a SHA-256. También aprovecharemos para deshabilitar las extensiones obsoletas de Netscape.

  3. Iremos a la pestaña Certificate signing request y pulsaremos en New Request. Aquí desplegaremos el combo Template for the new certificate y seleccionaremos HTTPS_server. Pulsaremos en Apply all.

  4. Nos iremos a la pestaña Subject y rellenaremos todos los datos que correspondan. En el campo commonName deberemos poner el nombre de dominio que queremos registrar.

  5. Generaremos una key pulsando Generate a new key de tipo RSA y de 2048 bits (es lo recomendado generalmente para un servidor web, de esto probablemente hable en otro artículo).

Definidendo el asunto del certificado
Figura 4. Definiendo el asunto del certificado
  1. Nos iremos a la pestaña Extensions. Aquí en Type seleccionaremos End Entity con critical y marcaremos Subject Key Identifier.

  2. Como comenté dependerá de la entidad que nos firme, pero suele ser recomendable definir la extensión Subject Alternative en la que podremos indicar varios nombres de servidor o fqdns. También podremos usar el wildcard *.eldominio.com. Si se rellena esta información, deberemos agregar también el commonName que hayamos establecido anteriormente. En la captura de pantalla se puede apreciar que he definido el dominio sin www y el dominio con www.

Definiendo las extensiones del certificado
Figura 5. Definiendo las extensiones del certificado
  1. Rellenar los datos de CRL y OCSP dependerá de la entidad certificadora, pero el proveedor debería de ofrecer una ruta CRL y un servicio OCSP para gestionar los certificados de su CA.

  2. En la pestaña Key usage deberíamos marcar las opciones que muestro en la captura de pantalla "Definiendo el uso del certificado".

Definiendo el uso del certificado
Figura 6. Definiendo el uso del certificado
  1. En la pestaña Advanced veremos las opciones OpenSSL que se han fijado para nuestro certificado. Si necesitáramos opciones que no estuviesen en la interfaz, podríamos agregarlas con Edit.

Propiedades avanzadas del certificado
Figura 7. Propiedades avanzadas del certificado
  1. Tras crear la solicitud, obtendremos un mensaje de indicándonos que hemos creado correctamente la solicitud.

Cuando solicitamos un certificado deberemos seguir las indicaciones que nos indique la entidad certificadora o CA. En la solicitud podemos habilitar las extensiones que queramos, pero luego será la CA la que determine lo que finalmente se creará en el certificado.
Algunas entidades certificadoras proporcionan un mecanismo web para este proceso. Esto realmente implica que sea ella la que nos genere el par de claves pública y privada y nos lo suministre. Personalmente recomiendo que lo hagamos nosotros mismos ya que de este modo reduciremos el grado de exposición de nuestra clave privada, teniendo control sobre el proceso.

3.1.2. Enviando nuestra petición

  1. Para enviar la petición deberemos exportar la solicitud de certificado. Para ello seleccionaremos nuestra petición recién creada y pulsaremos Export.

  2. El estándar para las peticiones de firma se conoce como PKCS#10 y XCA nos permitirá exportarlo en formato PEM (Base64, que se puede escribir en ascii) o en formato DER (formato binario). Esto dependerá de nuestro proveedor, pero si no nos dice nada y establece un cuadro de texto, deberemos exportarlo en formato PEM, abrir el fichero con un editor de texto y copiar y pegar el texto.

3.1.3. Importando el certificado firmado a XCA

  1. Supongamos que nuestra CA ha firmado nuestra petición y queremos incluirlo a XCA. Para ello en primer lugar importaremos el certificado de la CA que nos firma. Vamos a suponer que ya lo tenemos en un fichero.

  2. Para ello nos iremos a la pestaña Certificates y nos iremos a Import. Allí seleccionaremos el certificado de la CA.

  3. Ya lo habremos importado pero fijémonos que nos indica con un aspa roja, esto quiere decir que todavía no confiamos en la CA. Para ello pulsaremos el botón derecho y le daremos a Trust y diremos Always trust in this certificate.

  4. Una vez hecho esto, ya podremos importar nuestro certificado ya firmado por la CA. Veremos que automáticamente XCA crea la jerarquía de confianza. image

Listado con los certificados en la base de datos XCA
Figura 8. Listado con los certificados en la base de datos XCA
Como se puede deducir, no es necesario que los certificados y las claves hayan tenido que ser generadas previamente mediante XCA. Podemos partir de certificados y claves ya existentes y construir nuestra base de datos importándolos.

3.1.4. Exportando la clave y certificados a nuestro servidor web

  1. Con esto ya tenemos en nuestra base de datos nuestro certificado y claves. Para llevarlo a un servidor web, es tan sencillo como exportar el certificado y exportar la clave privada.

  2. En el caso de un apache en la pestaña Certificates pulsaríamos sobre nuestros certificado y daríamos a Export y PEM chain. De este modo tendríamos toda la cadena de certificación en un único fichero.

  3. A continuación nos iríamos a la pestaña Private Keys, seleccionaríamos la clave y pulsaríamos Export. En opciones seleccionaríamos PEM private (aunque también podríamos llevárnosla encriptada con cifrado simétrico).

3.2. XCA para gestionar los certificados OpenVPN

Supongamos que queremos desplegar una red VPN con la tecnología OpenVPN. Es una empresa pequeña, sin web de intranet y simplemente queremos una VPN para que los usuarios puedan conectarse mediante VPN al servidor de ficheros interno o a su equipo de trabajo mediante escritorio remoto. Por simplicidad se opta por crear una CA específica para el servicio VPN que se gestionará con XCA.

Existe abundante información de este procedimiento en Internet, aquí tienes un ejemplo de este caso de uso. Por ello no voy a repetir mucho más de lo que allí se comenta y únicamente voy a dar un guión del proceso y algunas pautas y consejos.

3.2.1. Creando la entidad certificadora (CA)

  1. En primer lugar crearemos la base de datos y modificaremos las opciones del mismo modo que hicimos en el caso de uso anterior.

  2. En la pestaña Certificates crearemos uno nuevo, pero en esta ocasión dejaremos la opción Create a self signed…​, seleccionaremos la plantilla CA y pulsaremos Apply all.

  3. En la pestaña Subject llenaremos la información a nuestro gusto y crearemos una key RSA de 4096 bits.

  4. En la pestañas Extension y Key usage dejaremos las opciones fijadas por defecto por la plantilla.

En esta ocasión, dado que es un ejemplo muy sencillo y sólo se usa para un servidor VPN, no especificaremos las opciones de revocación de certificados de ruta de CRL y OCSP. La configuración más simple sería dejar manualmente la CRL generada por XCA en el servidor VPN para que chequee y en el lado cliente no se chequearía contra ningún sitio.

3.2.2. Creando el certificado para el servidor vpn

  1. Crearíamos un certificado pero asegurándonos de que está con la opción de Use this Certificate for signing con nuestra CA.

  2. En template seleccionaríamos HTTPS_Server y pulsaríamos Apply All.

  3. Rellenaríamos la pestaña Subject con la información que deseáramos y generando una key de tipo RSA de 2048 bits. En este caso deberíamos prestar especial atención al campo commonName, en el que podríamos poner el nombre público o la dirección IP del servidor VPN. Esto nos podría ayudar a autenticar al servidor a los clientes.

  4. De nuevo, en la pestañas Extension y Key usage dejaremos las opciones fijadas por defecto por la plantilla.

3.2.3. Creando certificados para los clientes vpn

  1. En este caso procederíamos igual que con el servidor VPN, sólo que como template seleccionaríamos HTTPS_Client y pulsaríamos Apply All.

  2. Haríamos exactamente igual, pero en commonName podríamos poner el nombre del usuario y rellenar también el campo email.

  3. De nuevo, en la pestañas Extension y Key usage dejaremos las opciones fijadas por defecto por la plantilla.

3.2.4. Creando una lista de revocación

  1. Este paso sería especialmente útil para revocar certificados si a algún usuario le robasen el portátil, se infectase con un troyano, etc. Para ello, deberíamos irnos a la pestaña Revocation lists, pulsar al botón derecho sobre la lista vacía y darle a New.

  2. Ahora seleccionaríamos el tiempo de refresco de la lista. Dado que en este caso volcaríamos la lista "a mano", podríamos especificar un plazo largo de 6 meses o un año.

3.2.5. Exportando la información y configurando el servicio

Como el objetivo de este artículo es explicar XCA y no OpenVPN, no voy a entrar en la configuración. Simplemente algunos consejos:

  1. En el servidor necesitarás:

    1. exportar el certificado de la CA

    2. exportar el certificado sin cadena de certificación del servidor

    3. exportar la clave privada del servidor

    4. exportar una lista de revocación inicial

    5. puedes chequear algunos atributos del certificado como el commonName o el mail contra una lista admitida

  2. En el cliente:

    1. exportar el certificado de la CA, cliente y clave. Para ello te recomiendo que uses el formato PKCS#12. Simplificará la configuración y estará todo cifrado

    2. configurar en el cliente que chequee que el certificado es de tipo servidor

    3. configurar el cliente para que verifique que el nombre o ip al que se conecta coincide con el commonName del certificado que presenta el servidor

4. Conclusiones

Como hemos visto, XCA podría considerarse un frontend gráfico de la utilidad de línea de comandos openssl que proporciona el toolkit OpenSSL, que simplifica en gran medida la generación y la gestión de claves y certificados. Aun así esto no implica que no debamos conocer bien los conceptos con los que trabajamos: extensiones, rutas de validación, etc. Por ello mi consejo si estás empezando es que le dediques un tiempo a conocer previamente a OpenSSL para entender mejor qué hace y cómo funciona esta herramienta.

Una de las pegas que tiene es que la última versión disponible es de 2015. Esta "falta de mantenimiento" sin duda es un argumento en su contra, sin embargo, diré en su favor que "no es más que una simple interfaz gráfica", y que lo realmente crítico en su mantenimiento son las librerías criptográficas…​ y en este aspecto, OpenSSL está muy vivo.

Vimos también dos casos de uso bastante típicos, al primero le dediqué más espacio que al segundo porque ya existen numerosos recursos que lo tratan. Pudimos ver que para estos casos de uso y para otros similares…​ XCA es perfecto.

Sin embargo no traté el caso de uso de gestión de una completa PKI privada en una empresa. No lo hice por motivos evidentes de extensión. ¿Podría usarse para esto? Aquí como casi siempre la respuesta es "depende". Si necesitamos una PKI con la que gestionar miles de certificados, que implemente de manera automática procesos de firma, roles de usuarios, con necesidad de auditar todas las entradas y salidas, etc…​ la respuesta evidentemente es no.

Ahora bien, si se trata de gesiontar una PKI de una empresa pequeña, del orden de cientos de usuarios, con pocos administradores, creo que puede ser una buena herramienta.

comments powered by Disqus