PKI con Vault para seguridad TLS

La Gestión PKI con Vault es una solución moderna, robusta y altamente automatizable para proteger las comunicaciones en infraestructura digital mediante certificados TLS. En un contexto donde el enfoque Zero Trust se vuelve imprescindible, gestionar adecuadamente los certificados ya no es una opción, sino una necesidad crítica para la seguridad operativa. La falta de una gestión eficiente puede llevar a expiraciones inesperadas, ataques de intermediarios (MITM) o exposición de servicios internos mal protegidos.

Implementar una infraestructura de Public Key Infrastructure (PKI) con HashiCorp Vault permite no solo automatizar la emisión, renovación y revocación de certificados, sino también cumplir con los principios fundamentales de confianza mínima y segmentación segura.

Por ello, en este artículo te hablaré todo lo que debes saber sobre PKI y cómo lograr gestionarlo adecuadamente de forma automatizada. Empecemos.

1. Conceptos previos

Considero importantísimo tener claro los conceptos básicos y términos entorno a PKI y la seguridad con TLS. Por ello, te recomiendo no saltearte esta sección.

1.1. ¿Qué es un certificado digital?

Un certificado digital es como un «pasaporte electrónico» que asocia una identidad (por ejemplo, un dominio web o un servicio) con una clave pública. Este certificado es emitido por una autoridad certificadora (CA) confiable, que garantiza que esa asociación es válida.

1.2. ¿Qué es una clave privada?

Cada certificado tiene un par de claves: una clave pública, que puede compartirse abiertamente, y una clave privada, que debe mantenerse en secreto.
La clave privada es la que se utiliza para firmar o descifrar mensajes. Si esta clave se filtra o compromete, la seguridad del sistema se rompe por completo.

1.3. ¿Qué es TLS?

TLS (Transport Layer Security) es el protocolo que se usa para proteger la comunicación entre dos sistemas, como un navegador y un servidor web. Usa certificados digitales para establecer un canal cifrado y confiable. Si ves el candado en la barra de direcciones de un navegador, estás usando TLS.

1.4. ¿Por qué importa la renovación de certificados?

Los certificados tienen una fecha de expiración. Cuando un certificado expira, deja de ser válido y los sistemas que dependen de él dejarán de confiar en esa conexión, provocando errores o caídas. Por eso, es crítico contar con un mecanismo que gestione su renovación periódica de forma automática.

1.5. ¿Qué es una Autoridad Certificadora (CA)?

Una CA es una entidad de confianza que emite y firma certificados digitales. Puede ser pública (como Let’s Encrypt) o privada (como las que creas tú mismo con herramientas como Vault).
En una infraestructura interna, muchas organizaciones prefieren tener su propia CA privada, para tener mayor control y trazabilidad.

2. Importancia de PKI con Vault

En este blog ya he publicado algunos artículos sobre Vault. Pero si eres nuevo en el tema, te recomiendo empezar a leer Qué es Hashicorp Vault y luego Instalación de Hashicorp Vault o Probando Vault en Docker, para que puedas familiarizarte con esta tecnología de forma rápida.

2.1. ¿Qué es el motor PKI de Vault?

Es un componente de HashiCorp Vault que permite actuar como una CA interna. Con él puedes emitir, renovar y revocar certificados TLS de forma programática y segura, ideal para integraciones con CI/CD, microservicios y arquitecturas de Zero Trust.

2.2. ¿Por qué PKI con Vault es clave para Zero Trust?

La arquitectura Zero Trust exige autenticación y autorización continua entre sistemas, incluso dentro de una misma red. Esto implica que los certificados TLS no pueden ser tratados como elementos estáticos: deben estar gestionados de forma activa y confiable.

PKI con Vault permite que cada microservicio, API o componente de infraestructura tenga su identidad digital, firmada por una CA interna, y controlada mediante políticas de acceso centralizadas. La ventaja es doble: se reduce la superficie de ataque y se incrementa la trazabilidad de cada certificado emitido.

2.3. Los riesgos de una mala gestión de TLS

Aún hoy, muchas organizaciones gestionan sus certificados TLS manualmente, usando scripts dispersos o sin control centralizado. Esto genera múltiples riesgos:

• Certificados expirados que generan caídas de servicios críticos.
• Certificados duplicados o compartidos entre entornos, violando principios de seguridad.
• Dificultad para cumplir con auditorías de seguridad y normativas.

Implementar PKI con Vault automatiza todo el ciclo de vida de los certificados, previene errores humanos y mejora la observabilidad de todo el sistema de confianza.

2.3. Automatización de certificados TLS con PKI Vault

Uno de los mayores beneficios de usar Vault como motor PKI es su API first approach. Desde un pipeline de CI/CD puedes:

• Solicitar certificados on-demand
• Renovarlos automáticamente antes de expirar
• Revocar certificados comprometidos en tiempo real
• Aplicar políticas de validez según entorno (dev, staging, prod)

Gracias al PKI secrets engine, es posible generar una CA interna confiable y adaptada a tu topología, con soporte para SANs, TTL personalizados y claves RSA o ECDSA.

3. Implementación de PKI con Vault

La implementación base del motor de secretos PKI en Vault es relativamente sencilla, tal como lo mostraré a continuación.

3.1. Inicialización del motor de secretos PKI

En los siguientes comandos, se asume que ya se tiene una sesión iniciada con un token de root en Vault o con permisos administrativos similares.

Primero, se requiere activar el motor de secretos PKI, como sigue:

vault secrets enable pki

Ahora, hay que fijar la duración máxima de secretos del motor PKI a 10 años (87,600 horas), ya que por defecto tiene un valor de 30 días (impráctico para nuestra necesidad):

vault secrets tune -max-lease-ttl=87600h pki

Luego, hay que inicializar la instancia de CA (Certification Authority) en Vault de esta manera:

vault write pki/root/generate/exported \
  common_name=MI-EMPRESA-CA \
  ttl=87600h \
  key_bits=4096 \
  ou=TI \
  organization="Mi Empresa - CA" \
  country=PE \
  locality=Lima \
  province=Lima

El comando mostrado arriba crea la CA con estas características:

• Usa MI-EMPRESA-CA como nombre común (CommonName)
• La duración de la CA será de 10 años (87600 horas)
• Crea una llave RSA de 4096 bits de longitud
• Asigna unos atributos informativos propios de la empresa, tal como su nombre, localidad, país, entre otros.

Al ejecutar el comando, se mostrará en pantalla el valor de la llave privada por única vez, y también el valor del certificado raíz.

En caso se desee consultar nuevamente el certificado de la CA, se pude hacer de este modo:

vault read pki/cert/ca

O de estas maneras para visualizar de forma más directa el contenido:

vault read -field certificate pki/cert/ca

vault read -field certificate pki/cert/ca | openssl x509 -noout -text

3.2. Configuración de rol PKI

Un rol en Vault es similar a una plantilla, con ciertos atributos de configuración predefinido, restricciones y/o valores aceptables. Tratándose del motor de secretos PKI, un rol permite definir cosas como:

• Duración predeterminada y máxima de los certificados TLS
• Dominios y/o subdominios bajo los cuales crear los certificados
• Atributos informativos (localidad, país, unidad organizativa, etc)
• Extensiones X.509 válidas (Ejm: subjectAltName)
• Tipos y longitud de llaves privadas
• Entre otros

El definir un rol con muchos de estos parámetros con valores prefijados simplifica la creación de certificados sin necesidad de especificar cada uno de estos campos en cada ocasión.

Es así, este sería un rol PKI bastante genérico y de uso común para nuestra empresa:

vault write pki/roles/main-role \
  allowed_domains=miempresa.com,miempresa.local,miempresa.com.pe \
  allow_subdomains=true \
  max_ttl=4320h \
  ou=TI \
  organization="Mi Empresa" \
  country=PE \
  locality=Lima \
  province=LI

Este rol tiene estas características:

• Se llama main-role. Este nombre es arbitrario; puede ser cualquier nombre que desees.
• Es válido únicamente para los dominios miempresa.com, miempresa.local y miempresa.com.pe
• Sí se permite la creación de certificados con subdominios. (Ejm: www.miempresa.local, intranet.miempresa.com.pe)
• Duración máxima de certificados es de 180 días
• Otros atributos informativos del certificado (unidad organizativa, país, localidad, etc)

Importante:

• Este rol define una validez máxima de certificados de 180 días
• Sin embargo, el ajuste general del motor de secretos PKI se fijó que ningún certificado debería durar más de 90 días, no importa de qué rol provengan
• Por ende, la duración efectiva máxima de certificados TLS creados bajo este rol será de 90 días.
• Si bien main-role es el primer y único rol creado, nada nos impide que se puedan crear roles adicionales con parámetros y/o restricciones diferentes. Todo depende de nuestras necesidades.

3.3. Crear certificados TLS vía CLI

Una vez que ya se tiene configurado el motor de secretos PKI y se creó por lo menos un rol, es momento de poner en práctica la generación de certificados digitales.

En principio, se requiere que el usuario o aplicación que solicitará un certificado TLS a Vault con el rol creado tenga esta política asignada:

path "pki/issue/main-role" {
  capabilities = ["create", "update"]
}

La ruta contiene el nombre del rol, main-role, y requiere los permisos create y update.

Ahora, la creación de un certificado se realiza en un único paso (o comando) como este:

vault write pki/issue/main-role \
  common_name=intranet.miempresa.com \
  alt_names=intranet.miempresa.com \
  ip_sans=192.168.10.23 \
  ttl=60d

Este comando hace lo siguiente:

• Pide a Vault un certificado TLS (la solicitud y firma es automática, en un solo paso)
• El certificado es válido para el commonName intranet.miempresa.com y tiene la extensión subjectAltName (nombre alternativo) con el mismo valor.
• También tiene una extensión subjectAltName para la IP 192.168.60.23, de modo que el certificado es válido para conexiones tanto por nombre (Ejm: https://intranet.miempresa.com), como por IP (https://192.168.10.23)
• El certificado tiene una duración de 60 días.

La salida del comando podría no ser muy amigable, por lo que puede ser necesario copiar y pegar los campos mostrados en pantalla hacia archivos separados. Por ejemplo, guardar el campo certificate hacia un archivo intranet.miempresa.com.crt y el campo private_key hacia un archivo intranet.miempresa.com.key.

3.4. Crear certificados TLS vía Web UI

Los pasos mostrados en la sección anterior son más fáciles de realizar a través de la interfaz Web de Vault.

Primero, dirigirse a «Secret Engines» –> «pki»:

Ahora, acceder al rol PKI existente:

Luego clic en «Create certificate»:

Finalmente, completar los datos deseados para el certificado TLS:

Una vez creado el certificado, se puede copiar los campos de interés al portapapeles y guardarlos manualmente en archivos .crt o .key, o sino descargar un archivo PEM completo con toda la información embebida.

4. Conclusión

En este artículo he explicado la teoría sobre PKI y sus conceptos afines. Luego, entré a la materia principal del post con la explicación detallada de cómo gestionar certificados TLS con una Autoridad Certificadora privada implementada con Hashicorp Vault y su motor PKI.

Hacia el final, indiqué la forma semi-automática de crear certificados TLS a partir de un rol con un único comando (vía CLI) o unos pocos pasos (vía Web UI).

Sin embargo, la potencia de la automatización de certificados TLS con el motor PKI de Vault se lleva a cabo cuando se usa una de estas dos vías:

• Emisión automática de certificados con el Agente Vault (entornos de máquina virtuales)
• Emisión automática de certificados con el Vault Secrets Operator (entornos Kubernetes)

Ambos son puntos que merecen sus artículos dedicados en una próxima oportunidad.

Pero, hasta este punto espero que ya hayas comprendido el potencial que puede tener el motor de secretos PKI con Vault.

Si este artículo te parece interesante y te gustaría ponerlo en práctica, anímate a seguir los pasos aquí documentados. Si tienes inconvenientes, déjame un comentario para poder ayudarte.

¡Hasta la próxima!