Creación de PKI con easy-rsa

Todos conocemos la necesidad de tener certificados válidos para que no nos suplanten la identidad en internet, y también conocemos el precio de los mismos.

Aunque tenemos la alternativa y usar Let's Encrypt, con la limitante de que cada 3 meses tenemos que recordar renovarlo o hacer un script en cron que lo automatice.

Pero, ¿es realmente necesario pagar por certificados para un uso exclusivamente de nuestra red interna?

Imaginemos que tenemos varios servicios publicados en nuestra red (nextcloud, servidores web...) y no queremos pagar un wildcard o un certificado por cada uno. Podemos crear nuestra propia infraestructura de validación de certificados.

---

¿Qué es una PKI?

La criptografía asimétrica te da confidencialidad e integridad: si tengo tu clave pública, puedo cifrar algo que solo tú puedes descifrar, y puedo verificar una firma que solo tú pudiste generar.

Pero eso no resuelve autenticación: ¿cómo sé que la clave pública que tengo delante es realmente tuya y no la de alguien haciendo un ataque man-in-the-middle?

Aquí es donde entra en juego la PKI: es el conjunto de roles, políticas, procedimientos y sistemas que permiten emitir, distribuir, validar y revocar certificados digitales, de forma que una clave pública quede vinculada de forma verificable a una identidad (un FQDN, un usuario, un dispositivo, un servicio).

COMPONENTES DE LA PKI

Par de claves y certificado

Cada entidad (servidor, usuario, dispositivo) tiene un par de claves: privada (nunca sale de donde se genera) y pública. El certificado X.509 empaqueta esa clave pública junto con metadatos —titular, emisor, periodo de validez, uso previsto (key usage / extended key usage), SAN— y todo eso va firmado digitalmente por una autoridad de certificación.

Autoridad de Certificación (CA)

La CA es quien firma. Firmar un certificado es, en esencia, decir "yo, la CA, doy fe de que esta clave pública pertenece a esta identidad". Esa firma se verifica con la clave pública de la CA.

Una PKI no es "generar un certificado autofirmado y ya está", es una arquitectura de confianza con separación de roles (CA raíz, CA intermedia, RA), un ciclo de vida definido para cada certificado, y un mecanismo de revocación (CRL/OCSP) que permite retirar confianza antes de que expire por sí sola.

---

Generación de una PKI con easy-rsa

Easy-rsa es una herramienta desarrollada por el equipo de OpenVPN. No ofrece todo lo que una PKI debería, como los OCSP de revocación, pero para entornos controlados creo que es suficiente.

En cualquier caso, tenemos otras alternativas como step-ca que renueva los certificados automáticamente cada 24 horas, de forma que un compromiso caduca solo en vez de que alguien revoque a tiempo.

En primer lugar, deberemos copiar easy-rsa a nuestro directorio de trabajo preferido.

cp /usr/share/easy-rsa /opt/

Una vez hecho esto, entraremos en la nueva ubicación y modificaremos el fichero vars.

Estos son los parámetros que yo tengo ajustados en el fichero.

Ahora, inicializamos la PKI y generamos nuestra CA:

./easyrsa init-pki
./easyrsa build-ca nopass

Con init-pki inicializa o reinicializa el directorio de la PKI (Public Key Infraestructure) local en la carpeta pki/ dentro del directorio easy-rsa.

Concretamente:

• Crea la estructura de carpetas: pki/, pki/private/, pki/reqs/, pki/certs_by_serial/, etc.

• Genera el archivo pki/.rnd (datos aleatorios para OpenSSL) o similar según versión.

• Crea pki/serial (contador de números de serie de certificados) y pki/index.txt (base de datos de certificados emitidos).

• Si el directorio pki/ ya existe, lo borra por completo y lo vuelve a crear desde cero — es un paso destructivo, no incremental. Por eso easy-rsa pide confirmación interactiva salvo que uses --batch.

Si después de build-ca ponemos nopass no nos pedirá contraseña cada vez que queramos firmar un certificado.

En el servidor al que le vamos a generar un certificado deberemos inicializar su PKI y generar su par de claves y peticiones. En este caso, como va a ser el mismo servidor, no debemos volver a inicializar la PKI.

./easyrsa gen-req <Nombre_Servidor> nopass

Donde dice <Nombre_Servidor> es un nombre descriptivo, que se utiliza para identificar la petición. Por buenas prácticas se recomienda utilizar el mismo nombre del servidor o usuario al que va dirigido.

Al hacer el gen-req nos pedirá el CN (Common Name), que debe ser nombreservidor.dominio.tld.

Ahora deberemos firmar esa solicitud (el .req) con la CA.

./easyrsa sign-req server <Nombre_Servidor>

Los diferentes tipos de firmas son:

1. client

• Añade extendedKeyUsage = clientAuth

• nsCertType = client

• Uso: certificados para clientes VPN (los que se conectan).

2. server

• Añade extendedKeyUsage = serverAuth

• nsCertType = server

• Uso: el certificado del propio servidor.

3. ca

• Genera un certificado de CA intermedia, no un cert de entidad final. Firma con tu CA raíz un certificado que a su vez puede firmar otros certificados.

• Uso: solo si estás construyendo una jerarquía de PKI de dos niveles (root CA offline + intermediate CA online).