Tag: certificates

Gestión de certificados (PKI) – easy-rsa

Serie

1. Gestión de certificados (PKI) – easy-rsa
2. MQTT Broker (Mosquitto) con certificado servidor (self-signed)
3. MQTT Broker (Mosquitto) con certificado servidor (self-signed) y certificado en los clientes
4. MQTT Broker (Mosquitto) con certificado servidor (Let’s Encrypt)
5. Formatos de Certificados: PEM, DER y PKCS#12 y Manipulación de Claves Privadas

Introducción a la Infraestructura de Clave Pública (PKI)

Una PKI, o Infraestructura de Clave Pública, es un sistema que gestiona certificados digitales y claves para garantizar comunicaciones seguras. Vamos a desglosar los conceptos básicos.

Conceptos Clave

• PKI: Es el sistema completo que conecta Certificados de Autoridad (CA), claves y certificados para garantizar la confianza entre entidades.
• CA (Certificate Authority): Es el “jefe” de la PKI. Firma y valida certificados, garantizando que son de confianza.
• Certificado: Documento digital que incluye una clave pública, información sobre la entidad, y la firma del CA. Es como un pasaporte digital.
• Solicitud de Certificado: Es un “borrador” del certificado que una entidad envía al CA para que lo firme.
• Par de Claves (Keypair): Un conjunto de dos claves: una pública (para compartir) y otra privada (secreta). Por ejemplo, la pública es como tu dirección de correo y la privada como la contraseña.

¿Qué es un CA y por qué es importante?

El CA es el núcleo de una PKI y su clave privada es extremadamente sensible porque firma todos los certificados. Para protegerla, se recomienda mantenerla en un entorno seguro, como un sistema dedicado o incluso desconectado de la red.

¿Cómo funciona todo esto?

1. Creación del CA: Se genera un par de claves y la estructura necesaria para gestionar certificados.
2. Solicitud de Certificado: Un cliente (por ejemplo, un servidor VPN) crea un par de claves y envía su solicitud al CA.
3. Firma y Certificado: El CA verifica la solicitud y utiliza su clave privada para firmar el certificado, que luego devuelve al cliente.

¿Cómo se verifica un certificado? Ejemplos prácticos

La verificación de certificados varía según el contexto, y quiero explicarlo con dos ejemplos claros: una conexión a una VPN, donde yo tengo un par de claves y un certificado, y una conexión a un banco, donde no necesito un par de claves, solo la confianza en la CA.

Ejemplo 1: Conexión VPN (yo tengo mi par de claves y certificado)

Cuando me conecto a una VPN, tanto el cliente como el servidor necesitan un par de claves (pública y privada) y certificados firmados por la misma CA. El proceso es el siguiente:

1. Yo genero mi par de claves y solicito un certificado al CA, que verifica mi identidad y firma mi certificado.
2. Cuando intento conectar al servidor VPN, este me presenta su certificado.
3. Yo verifico que el certificado del servidor fue firmado por el CA en el que confío.
4. Luego, envío mi propio certificado al servidor, que hace la misma verificación con su copia del CA.
5. Si todo es válido, ambos usamos nuestras claves privadas para intercambiar información cifrada y establecer una conexión segura.

Por ejemplo, si trabajo remotamente y necesito acceder a la red de mi empresa, configuro un cliente VPN con mi certificado y claves. El servidor verifica que yo soy quien digo ser y me deja entrar solo si la verificación es correcta.

Ejemplo 2: Conexión a un banco (sin par de claves, solo confianza en la CA)

Cuando accedo a la web de mi banco desde mi navegador, no necesito un par de claves personal. Simplemente, confío en los certificados emitidos por las CA incluidas en la lista de confianza de mi navegador. Así funciona:

1. El servidor del banco me envía su certificado.
2. Mi navegador verifica que el certificado fue firmado por una CA en su lista de confianza y que este no está caducado ni revocado.
3. Si la verificación es exitosa, se establece una conexión segura mediante TLS/SSL.
4. Durante la conexión, el banco usa su clave privada para demostrar que es legítimo, firmando datos que mi navegador valida con la clave pública incluida en el certificado del banco.

Por ejemplo, cuando accedo a https://mi-banco.com, mi navegador me muestra un candado en la barra de direcciones. Esto significa que ha validado el certificado del banco y ahora la conexión es segura. Aunque yo no tengo claves en este caso, confío en la autoridad que firmó el certificado del banco.

Vamos a crear nuestra propia PKI y la gestión de certificados usando easy-rsa

Easy-RSA es una herramienta poderosa y sencilla para gestionar una infraestructura PKI (Infraestructura de Clave Pública). Con ella puedo emitir certificados para servidores VPN, páginas web, y clientes que necesiten conexiones seguras. Aquí explicaré cómo utilizar Easy-RSA para construir esta infraestructura y cómo interpretar sus resultados.

Importante mencionar que easy-rsa no son más que unos scripts que simplifican el uso de OpenSSL que es la verdadera herramienta que hay por detrás gestionando los certificados, claves y demás.

Obtener easy-rsa:

git clone https://github.com/OpenVPN/easy-rsa.git

Configuración del archivo vars en Easy-RSA

El archivo vars permite configurar parámetros básicos y avanzados antes de iniciar el PKI con init-pki, ahorrando tiempo y garantizando consistencia. Para empezar, copio vars.example a vars y relleno las partes que me interesen, como:

• Datos del certificado: País, ciudad, organización, etc.
• Claves y algoritmos: Tamaño (2048 bits) y tipo (RSA o EC).
• Duración: Expiración de la CA y certificados.

set_var EASYRSA_REQ_COUNTRY "ES"
set_var EASYRSA_REQ_ORG "MiEmpresa"
set_var EASYRSA_KEY_SIZE 2048
set_var EASYRSA_CA_EXPIRE 3650
set_var EASYRSA_CERT_EXPIRE 825

Paso 1: Preparar Easy-RSA

Primero, descargo Easy-RSA desde su repositorio oficial. Como no requiere instalación, simplemente extraigo el archivo comprimido (.tar.gz para Linux/Unix o .zip para Windows) en el directorio que prefiera.

Para comenzar, inicializo el directorio de PKI con:

./easyrsa init-pki

Esto crea una estructura de directorios básica para gestionar los certificados. El directorio pki incluye:

• private/: Guarda claves privadas (debe mantenerse muy seguro).
• reqs/: Contiene solicitudes de certificados.
• issued/: Almacena certificados emitidos.
• ca.crt: El certificado de la CA (Autoridad Certificadora).
• private/ca.key: La clave privada de la CA, crítica para la seguridad de toda la infraestructura.

Paso 2: Crear la Autoridad Certificadora (CA)

La CA es el corazón de mi PKI. Es quien firma los certificados y garantiza su validez. Creo la CA con:

./easyrsa build-ca

Durante este proceso, defino un nombre común (Common Name, CN) para identificar mi CA, y se me pedirá configurar una frase de contraseña fuerte para proteger la clave privada (ca.key). Este archivo es extremadamente sensible, y su seguridad es crítica.

El resultado principal de este paso es:

• ca.crt: El certificado público de la CA, que compartiré con clientes y servidores para verificar certificados.

Paso 3: Generar claves y solicitudes de certificados

Para que un cliente o servidor VPN funcione, primero genero un par de claves (privada y pública) junto con una solicitud de certificado (CSR). Esto se hace con:

./easyrsa gen-req <nombre-del-certificado|FQDN>
# muy importante usar FQDN (Fully Qualified Domain Names) para evitar
# problemas de matching con los hostnames usados en la conexión.

Por ejemplo, para un servidor VPN:

./easyrsa gen-req vpn-server.example.tld

El comando genera dos archivos:

1. private/<nombre-del-certificado>.key: La clave privada. Este archivo debe permanecer en el servidor o cliente correspondiente y nunca compartirse.
2. reqs/<nombre-del-certificado>.req: La solicitud de certificado (CSR). Este archivo se envía al CA para ser firmado.

Paso 4: Firmar solicitudes de certificados

Una vez que tengo la solicitud (.req), la importo en el CA y la firmo. Esto se realiza con:

1. Importar la solicitud

# solo hay que hacer este paso si el certificate request 
# lo hemos copiado de otra máquina. Esto lo coloca en path
# para que todo vaya automático, incluidas futuras 
# renovaciones.
./easyrsa import-req /the-path/vpn-server.example.tld.req vpn-server.example.tld

2. Firmar la solicitud

./easyrsa sign-req server vpn-server.example.tld

Easy-RSA generará un certificado firmado en pki/issued/servidor-vpn.crt. Este archivo es lo que el servidor VPN utiliza para identificarse de forma segura ante sus clientes.

Paso 5: Configuración de un servidor y cliente VPN

Servidor VPN

Para configurar un servidor VPN (como OpenVPN), necesitaré los siguientes archivos generados por Easy-RSA:

1. Clave privada (private/servidor-vpn.key): Usada por el servidor para encriptar las comunicaciones.
2. Certificado firmado (issued/servidor-vpn.crt): Garantiza que el servidor es confiable.
3. Certificado de la CA (ca.crt): certificado y clave pública de nuestra PKI.

Estos archivos se colocan en el directorio de configuración del servidor VPN y se referencian en su configuración.

Cliente VPN

Hay que repetir el paso 4, en este caso una buena práctica es poner como “nombre-del-certificado” el nombre del usuario, o el cliente, que pide el certificado de acceso. En algunos casos de uso, eso permite no tener que pasar por un proceso de autenticación.

Después de generar la petición y haberla importado, como indica la primera parte del paso 5. Hay que ir muy en cuidado con el segundo paso. Al firmar el certificate request hay que hacerlo indicando que su uso será de cliente, no de servidor.

# creamos el certificate request
./easyrsa gen-req mi-nombre-de-usuario

# importamos el certificado si es necesario en la PKI
./easyrsa import-req /the-path/mi-nombre-de-usuario.req mi-nombre-de-usuario

# firmamos el certificate request indicando el uso como cliente
./easyrsa sign-req client mi-nombre-de-usuario

Después de firmar el certificate-request ya tenemos los ficheros que deberá usar el cliente para conectarse al servidor:

1. Clave privada (private/mi-nombre-de-usuario.key): Usado por el cliente para encriptar las comunicaciones.
2. Certificado firmado (issued/mi-nombre-de-usuario.crt): Garantiza que el servidor es confiable.
3. Certificado de la CA (ca.crt): certificado y clave pública de nuestra PKI.

NOTA:

Cuando se firma un certificado las posibles opciones a seleccionar son:

• client – es para TLS client, típicamente usado para usuarios de VPN, o para navegadores Web
• server – para TLS server, típicamente servidores Web y servidores VPN.
• ca – cuando queremos crear CA (Certificate Authorities) en cascada, esto emite un certificado intermedio. Técnicamente, lo llaman chaining certificate.
• serverClient – certificado que serve tanto para cliente como para servidor TLS.

Paso 6: Configuración para servidores web

El proceso es similar para un servidor web (HTTPS). Genero una solicitud de certificado para el dominio del servidor (por ejemplo, mi-servidor.com) y la firmo con la CA. Los archivos necesarios serán:

1. Clave privada (private/mi-servidor.key): Exclusiva del servidor web.
2. Certificado firmado (issued/mi-servidor.crt): Identifica al servidor web.
3. Certificado de la CA (ca.crt): Permite a los navegadores validar la conexión.

Estos archivos se configuran en el servidor web (como Apache o Nginx) para habilitar HTTPs.

Gestión de certificados emitidos, CRL y Validación en Tiempo Real con OCSP

Easy-RSA no solo permite emitir y revocar certificados, sino que también facilita la gestión de la revocación mediante la generación de listas de certificados revocados (CRL) y la implementación de validación en tiempo real a través de OCSP. Cuando se detecta que una clave privada ha sido comprometida o un certificado ya no es necesario, se procede a su revocación:

1. Revocar un certificado:
   Utiliza el comando: ./easyrsa revoke <nombre-del-certificado> Esto marca el certificado como revocado dentro de la base de datos de la PKI.
2. Generar la CRL:
   Una vez revocados los certificados, es necesario generar una nueva lista de revocación. Esto se realiza con: ./easyrsa gen-crl Este comando genera dos ficheros:
   • crl.pem: La CRL en formato Base64.
   • crl.der: La CRL en formato binario.
     Estos archivos deben publicarse en un servidor accesible para que los clientes puedan descargarlos y comprobar el estado de los certificados.

Aunque la CRL es la solución tradicional para gestionar certificados revocados, presenta limitaciones como el tamaño de la lista y la necesidad de descargarla por completo en cada comprobación. Para solventar estas deficiencias, se puede implementar OCSP (Online Certificate Status Protocol).

OCSP es un protocolo definido en el RFC 2560 que permite a un cliente consultar el estado de un certificado de forma puntual y en tiempo real, sin tener que procesar toda la CRL. Entre sus ventajas destacan:

• Información actualizada: Permite obtener el estado de revocación de un certificado al momento de la consulta.
• Eficiencia: Reduce el tráfico y la carga de procesamiento en el cliente, ya que se consulta solo el certificado específico.
• Privacidad: Evita la exposición de información potencialmente sensible contenida en la CRL.
• Escalabilidad: Emplea mecanismos optimizados (a menudo basados en motores de base de datos) para gestionar consultas incluso en entornos con un gran número de certificados.

Implementación de un Servidor OCSP con OpenSSL:

Para poner en marcha un servidor OCSP, utiliza el siguiente comando:

openssl ocsp -index /ruta/a/tu/index.txt -port 2560 -ignore_err -rsigner /ruta/a/tu/ocsp.crt -rkey /ruta/a/tu/ocsp.key -CA /ruta/a/tu/ca.crt -text -out /ruta/a/tu/log_ocsp.txt &

Donde:

• -index indica el archivo que contiene el índice de certificados emitidos.
• -port define el puerto en el que el servidor OCSP escuchará (en este ejemplo, 2560).
• -ignore_err permite que el servidor continúe operando incluso si recibe peticiones malformadas.
• -rsigner y -rkey especifican el certificado y la clave privada del OCSP responder.
• -CA señala el certificado de la CA emisora.
• -text -out guarda un log detallado de las operaciones.

Para consultar el estado de un certificado (por ejemplo, newcert.pem), ejecuta:

openssl ocsp -CAfile /ruta/a/tu/ca.crt -issuer /ruta/a/tu/ca.crt -cert newcert.pem -url http://tu-dominio:2560 -resp_text

Esta consulta permite verificar de forma inmediata si el certificado está revocado o sigue siendo válido.

Integrar la generación y publicación de CRL con un servidor OCSP proporciona un mecanismo completo para la gestión de certificados emitidos. Mientras que la CRL ofrece una solución tradicional basada en la descarga de una lista completa, OCSP permite a los clientes obtener el estado de un certificado de forma ágil y en tiempo real, optimizando el proceso de validación y reduciendo la carga en la red. Este enfoque combinado asegura que, tanto en entornos de pruebas como en producción, se disponga de mecanismos robustos para mantener la integridad y seguridad de la infraestructura PKI.

Renovar un certificado

Normalmente, poco antes de caducar un certificado se pide su renovación. Esto emitirá otro fichoero de certificado firmado por la CA como el que se emetió la primera vez, pero con una nueva fecha de caducidad:

./easyrsa renew <nombre-del-certificado>

una vez generado el nuevo certificado en:

• issued/mqtt.example.tld.crt – certificado renovado

es buena idea ejecutar el siguiente comando para asegurarse que el viejo certificado queda obsoleto:

./easyrsa revoke-renewed <nombre-del-certificado>

esto nos acaba forzando a generar una nueva lista de certificados revocados. O sea, hay que ejecutar:

./easyrsa gen-crl

y en consecuencia distribuir el nuevo fichero CRL.

Conclusión

Easy-RSA simplifica la creación y gestión de una infraestructura PKI, lo que me permite emitir y administrar certificados para VPNs y servidores web. Sus outputs, como las claves privadas, certificados firmados, y el certificado de la CA, son los componentes esenciales para garantizar conexiones seguras. Con esta herramienta, puedo construir mi propia red confiable para asegurar tanto servidores como clientes en diferentes escenarios.

Referencias

• https://github.com/OpenVPN/easy-rsa
• https://github.com/OpenVPN/easy-rsa/blob/master/README.quickstart.md
• https://easy-rsa.readthedocs.io/