XCA: interesante front-end para openssl

Hoy les voy a mostrar algunas características de XCA, un interesante front-end grafico para realizar varias tareas con claves asimétricas y certificados digitales utilizando openssl.

Se trata de un front-end gráfico basado en Qt que permite crear y administrar autoridades de certificación, y ayuda a los usuarios a crear y administrar claves, certificados, peticiones de firma de certificados, listas de revocación, etc.

Todos los datos se almacenan en una base de datos local, un archivo, de manera encriptada. Esta base de datos a su vez puede ser exportada, lo mismo que los certificados almacenados e la misma.

Es una aplicación multiplataforma, por lo que también puede utilizarse en Windows y MacOS.

Otra característica interesante que le encontré, es que permite almacenar plantillas de creación de certificados, con todos los datos guardados, de modo que al crear certificados nuevos resulta mucho más fácil cargar los datos por medio de la plantilla, si es que debemos crear varios certificados similares.

Listo de intros, vamos con la práctica.

Instalando XCA

En mi caso lo he instalado en Arch Linux, así que lo he instalado directamente desde los repositorios oficiales de la distro:

sudo pacman -S xca

En Debian:

sudo apt install xca

Creando la base de datos de XCA

Lo primero que debemos hacer cuando iniciamos la aplicación es crear la base de datos, o, si ya disponemos de una, podemos simplemente abrirla.

Al crearla nos va a solicitar una contraseña para poder protegerla (esto me recuerda a Keepass)

La base de datos creada ya nos habilitará las pestañas y menus para trabajar con claves y certificados.

Un tip, dependiendo de la versión que usemos de XCA, cuando creamos la base de datos podemos configurar algunos parámetros predeterminados.

Entre ellos, el HASH predeterminado. Aquí recomiendo como mínimo seleccionar SHA-256. Esto se configura entrando a File->Options con la base de datos creada o abierta.

Un ejemplo completo

Vamos a realizar un ejemplo completo de varias de las funcionalidades provistas por XCA:

• Creación de una plantilla/template (opcional)
• Creación de una autoridad certificante.
• Creación de un par de clave y certificado para un servidor.
• Firma del certificado por medio de la autoridad certificante previamente creada.

Creación de una plantilla (opcional)

Primero vamos a crear una plantilla para facilitarnos las cosas, evitando reescribir todo el contenido cada vez que creemos un certificado para nuestra organización.

Vamos a la pestaña Templates, ahí a New Template. Podemos elegir varios tipos de templates de base. En mi caso voy a elegir un template vacío.

En el template voy a cargar los datos generales que quiero en todos mis certificados, sin importar si se trata de certificados de CA o de servicio.

En la pestaña de Extensions podemos seleccionar si queremos que sea un template de CA o no. En mi caso lo voy a dejar en blanco, sin modificar nada.

Ya tenemos el template creado! Sigamos.

Creación de la autoridad certificante (CA)

Creemos una CA nueva para firmar nuestros certificados digitales. La CA no es mas que un par de clave y certificado digital utilizado para firmar otros certificados.

Vamos a la pantalla principal, pestaña Certificates, y creamos un nuevo certificado.

En la pantalla principal de certificado, al final, podemos cargar extensiones y templates, de modo que resulta más simple sin tener que escribir nada.

Veamos que en la parte superior tenemos varias tabs. Las más importantes:

• Subject: aquí se cargan los datos del certificado.
• Extensions: aquí se carga el tipo de certificado (si es de CA o no).

Primero cambiamos las extensiones, recordemos que una extensión permite que el certificado sea de CA, lo que permitirá a XCA firmar otros certificados utilizando su clave privada.

En el desplegable del final seleccionamos la CA predeterminada, [default] CA, y damos click en Apply Extensions. De esta forma se completará la pestaña de extensiones.

Acto seguido, podemos cargar de la misma forma los datos del certificado. Ahora en el desplegable elegimos nuestro template, y damos click en Apply subject. Esto rellenará los campos en la tab de subject.

Ahora ya tenemos casi todos los datos listos!

De la pestaña Extensions no es necesario modificar nada. Pero por ejemplo podríamos modificar las fechas de validez del certificado digital.

En la tab Subject podemos agregar el nombre del certificado, el resto de los datos ya estarán cargados. En mi caso también cargué el common name, que era un dato que no puse en el template.

Y si han estado siguiendo mi serie sobre criptografía aplicada, sabrán que para un certificado existe una clave privada que, en este caso nunca creamos. Así que vamos a dar clic en Generate a new key en la parte inferior.

Esto nos abrirá un Pop-Up con un par de opciones. No es necesario cambiar nada, pero como recomendación, recuerden crear una clave RSA de, mínimo, 2048 bits. También pueden crear otros tipos de claves, claro, todas son seguras mientras no surjan computadoras cuánticas 😛

Al crear la clave y finalmente crear el certificado, ya los veremos a ambos en las tabs de Private Keys y Certificates respectivamente, en la ventana principal de XCA.

Ya tenemos la CA creada! Vamos a por los certificados y claves de servicio.

Creación del par clave+certificado para un servidor

Vamos a crear un nuevo certificado digital, en este caso, para nuestro servidor.

Veamos la pantalla principal de creación del certificado:

Aquí tenemos dos puntos importantes. Uno, la sección de firma (Signing) ya figura nuestra CA creada anteriormente para firmar el certificado. Podemos usarla, o crear un certificado autofirmado. Vamos a usarla.

Debajo, ahora vamos a cargar las extensiones desde el template de TLS_server, y los datos del subject, igual que antes, desde nuestro template personalizado. Estos pasos son iguales a los mostrados arriba, salvo que las extensiones son de TLS_server y no de CA, así que no hice capturas.

En la pestaña de Subject vamos a cambiar el common name y el nombre de nuestro certificado, y vamos a generar también la clave privada igual que hicimos con la CA.

En la pestaña de Extensions podemos, al igual que antes, cambiar las fechas de validez, y otros parámetros.

Como particularmente quiero que este certificado sea válido para los dominios juncotic.com, www.juncotic.com, y para la IP del servidor (supongamos, 11.22.33.44), vamos a añadir estos datos en la sección de Subject Alternative Names (damos click en Edit en esa sección).

Aquí voy a añadir los dos valores faltantes (el common name ya estará cargado de manera predeterminada).

Al dar Apply lo veremos en la pantalla principal del certificado:

Y listo! Ya tenemos nuestro certificado de servidor web firmado por nuestra propia CA!

Exportando el certificado

Si vamos a la lista de certificados veremos que ya tenemos el certificado de nuestro servidor HTTPS creado, y dependiente de la CA (esto es porque está firmado por la misma).

Podemos dar click derecho sobre el certificado, e ir a la opción Export.

Aquí tenemos muchos formatos para diferentes aplicaciones. Los formatos PEM son los que suelen usarse en Linux, los DER también, los formatos cifrados PKCS#12 los he visto en Windows.

Para ver algunas diferencias entre los formatos principales los invito a leer x.509: Certificados digitales DER, CRT y CER.

Veamos un ejemplo simple, exportemos en formato PEM el archivo, y analicemos el contenido como aprendimos a hacerlo en la serie sobre criptografía, usando openssl 🙂

En mi caso el archivo exportado fue /tmp/JuncoTIC_HTTPS.crt, y lo analicé usando este comando:

╰$ openssl x509 -in /tmp/JuncoTIC_HTTPS.crt -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1071410934867182662 (0xede6a91953a4446)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = AR, ST = Mendoza, L = San Rafael, O = JuncoTIC, OU = Blog, CN = root CA, emailAddress = diego@juncotic.com
        Validity
            Not Before: Apr 19 03:02:00 2023 GMT
            Not After : Apr 18 03:02:00 2024 GMT
        Subject: C = AR, ST = Mendoza, L = San Rafael, O = JuncoTIC, OU = Blog, CN = juncotic.com, emailAddress = diego@juncotic.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:c9:fe:0c:57:35:c8:54:45:06:90:ff:53:ab:5a:
                    [...]
                    95:67
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                04:36:D2:A5:71:99:F7:56:D6:B2:AF:F8:EA:95:54:F8:87:59:1B:16
            X509v3 Key Usage:
                Digital Signature, Non Repudiation, Key Encipherment, Key Agreement
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Subject Alternative Name:
                DNS:juncotic.com, DNS:www.juncotic.com, IP Address:11.22.33.44
            Netscape Cert Type:
                SSL Server
            Netscape Comment:
                xca certificate
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        61:e8:38:4b:d6:43:b4:63:8a:f2:3f:b9:7a:50:50:80:76:9b:
        [...]
        80:e5:a4:96:e2:3c:9f:7e

Las líneas resaltadas muestran info interesante. El comando que escribí para ver la salida, los datos del certificado digital, y los nombres alternativos cargados en las extensiones de dicho certificado.

En este caso no se ve quién firma, pero sabemos que es la firma de nuestra CA… cierto? No me creen?

Bueno, ya que insisten en llegar al último detalle, verifiquemos que es así. Exportamos el certificado de la CA de la misma forma (/tmp/JuncoTIC_CA.crt en mi caso), y procedemos a verificar la firma:

Conclusiones de XCA

Esta herramienta me ha parecido muy interesan te para gestionar certificados digitales y CA’s de manera sencilla, si es que no estamos muy acostumbrados a utilizar openssl directamente en terminal.

Este artículo ha sido una introducción muy breve a esta herramienta, pero pueden explorarse otros aspectos importantes, a saber:

• Generación de una lista de certificados revocados (CRL – Certificate Revocation List) en blanco. Esta lista se va a ir verificando de manera predeterminada una vez por mes, pero podemos cambiar este parámetro. Esta lista contendrá todos los certificados revocados por nosotros debido a alguna razón, como certificado suplantado, clave privada comprometida, etc.
• Creación de peticiones de firma de certificados para ser firmadas por CAs externas.

El tema de CRL da para más, así que seguramente en un futuro toque ese tópico también desde openssl.

Como ventaja de XCA respecto de OpenSSL puro, rescato que es muy simple de utilizar, y para gestionar una cantidad moderada de certificados, claves y autoridades certificantes resulta muy cómodo.

Otra ventaja es que permite exportar de manera sencilla los certificados en diferentes formatos para diferentes usos, eso está bueno si disponemos de infraestructuras mixtas.

Como desventaja, la misma que para cualquier front-end gráfico: no permite automatizar tareas. Si queremos, por ejemplo, crear scripts que levanten servicios y automáticamente generen certificados, lo tenemos que hacer, por ejemplo, desde Bash, y ahí es más conveniente usar openssl por comandos.

Otra desventaja es que, en general, el desarrollo de front-ends va un paso atrás respecto de la herramienta original, así es que algún agregado adicional en openssl en este caso podría demorar en ser cargado en XCA por los desarrolladores.

En fin, muy interesante herramienta, más que útil en muchos entornos. Igualmente recomiendo conocer algo de openssl, puede ayudar a entender algunos conceptos dentro de XCA.

Espero que les sea de utilidad!

Como siempre, ya saben dónde encontrarme por dudas y consultas.

Hasta la próxima!