Operar una PKI privada: implementar OpenSSL y CFSSL, CRL/OCSP e integración con HSM

En esta entrada explico cómo operar una PKI privada —es decir, una Public Key Infrastructure (PKI) interna que emite y gestiona certificados X.509. Una PKI es central para TLS, firma de código, autenticación de clientes y accesos VPN. Trato aspectos prácticos: decisión OpenSSL vs. CFSSL, arquitectura de CA, CRL (Certificate Revocation List) y OCSP (Online Certificate Status Protocol) para la comprobación de revocación, así como la integración de HSM mediante PKCS#11. La audiencia objetivo son administradores, ingenieros de sistemas y operadores: por ello el enfoque está en la operación, riesgos, pasos de verificación, resolución de problemas y estrategias de recuperación.

¿Por qué operar una PKI privada?

Una PKI privada proporciona control sobre las reglas de emisión, los periodos de validez y el material de clave. A diferencia de las CAs públicas, está pensada para certificados internos que no figuran en el almacén raíz del navegador. Esto permite periodos de validez cortos, despliegues automatizados y una aplicación estricta de políticas. Sin embargo, los riesgos son mayores: compromiso de la clave raíz, configuración defectuosa de revocación o falta de automatización pueden poner en riesgo la disponibilidad y la seguridad.

Decisiones arquitectónicas fundamentales

Antes de implementar debe aclarar cuestiones arquitectónicas. Determinantes son la jerarquía de CA, el grado de automatización, el almacenamiento de las claves y la estrategia de revocación.

Topología de CA: Root, Sub‑CA, Issuing

La práctica recomendada es una jerarquía multinivel: una Root‑CA mantenida offline (Root‑Key, ancla de confianza superior) y una o varias Sub‑CAs en línea (Issuing CAs) que firman los certificados activos. Esta separación reduce el riesgo: una Issuing CA comprometida es más manejable; el Root‑Key permanece seguro offline durante periodos prolongados.

Elección de software: OpenSSL vs. CFSSL (vs. Vault)

OpenSSL es un toolkit flexible y personalizable; adecuado para PKI sencillas de bajo volumen o flujos de trabajo controlados por administradores. CFSSL (CloudFlare SSL) es un servidor PKI especializado con REST API, configuración JSON y automatización integrada. HashiCorp Vault ofrece además un modelo tipo KMS con certificados dinámicos y políticas. Elija según sus requisitos:

• OpenSSL: control total, scripts, pero requiere más desarrollo propio para APIs y automatización.
• CFSSL: preparado para API, vías de automatización más sencillas, adecuado para DevOps/CI internos.
• Vault: fuerte funcionalidad de gestión de políticas y secretos; recomendable si ya dispone de Vault en uso.

Requisitos previos y fundamentos de seguridad

Antes de implementar necesita políticas claras: tamaños de clave (2048/3072/4096 RSA o ECDSA P‑256/P‑384), periodos de validez, procesos de renovación, registro de auditoría y roles (p. ej. oficial de CA, auditor). HSM (Hardware Security Module) permite proteger las claves privadas frente a extracción; PKCS#11 es un API estándar para ello. Defina planes de copia de seguridad y recuperación para el material de claves y las bases de datos de la CA.

Políticas: Certificate Policy (CP) y Certification Practice Statement (CPS)

CP/CPS son normas documentadas que regulan la emisión, el uso y la revocación. Incluso si son internas, estos documentos son esenciales para la claridad operativa y como referencia en auditorías.

Paso a paso: OpenSSL Root y Sub‑CA (ejemplo breve)

Este ejemplo muestra lo mínimo: generar la Root CA offline y una Sub‑CA para la operación de firma. Aclaración: OpenSSL se configura mediante un archivo de configuración (objetivo: extensiones, rutas). Los fallos ocurren con frecuencia por permisos incorrectos o por olvidarse de los archivos de número de serie/índice.

Generar Root CA (offline):

# Root private key (offline, auf HSM empfohlen) und self-signed cert (10 Jahre)
openssl genpkey -algorithm RSA -out root.key.pem -pkeyopt rsa_keygen_bits:4096
openssl req -x509 -new -nodes -key root.key.pem -sha256 -days 3650 -out root.cert.pem -subj "/C=DE/O=ACME/OU=PKI Root/CN=ACME Root CA"

Crear Sub‑CA y firmarla con la CA raíz (Sub‑CA en línea):

openssl genpkey -algorithm RSA -out subca.key.pem -pkeyopt rsa_keygen_bits:4096
openssl req -new -key subca.key.pem -out subca.csr.pem -subj "/C=DE/O=ACME/OU=PKI SubCA/CN=ACME SubCA"
openssl x509 -req -in subca.csr.pem -CA root.cert.pem -CAkey root.key.pem -CAcreateserial -out subca.cert.pem -days 1825 -sha256 -extensions v3_ca -extfile /etc/ssl/openssl.cnf

Peligro habitual: al copiar las claves raíz al sistema en línea se compromete la raíz. Es preferible un flujo de firma: firmar el CSR de forma offline y transferir en línea únicamente el certificado de la Sub‑CA.

Integración de HSM: por qué y cómo (PKCS#11)

Los HSM protegen las claves privadas físicamente y evitan su exportación sencilla. PKCS#11 es una API independiente de la plataforma mediante la cual el software accede a los HSM. SoftHSM es una implementación de PKCS#11 basada en software para pruebas; los Cloud‑HSMs (AWS, Azure, Google) ofrecen HSM gestionados con pasos de integración propios.

SoftHSM como prueba

SoftHSM es útil para pruebas; no sustituye a un HSM productivo certificado FIPS. Para crear una clave en SoftHSM:

# Initialisierung (Beispiel mit SoftHSM2)
softhsm2-util --init-token --slot 0 --label "test-token" --pin 1234 --so-pin 5678
# Import eines RSA-Schlüssels (PKCS#12) in SoftHSM
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so -l --pin 1234 --import mykey.p12 --type private

En entornos de producción, configure su software de CA (OpenSSL, CFSSL, Vault) para que las claves privadas permanezcan en PKCS#11 y las operaciones de firma se ejecuten en el HSM. OpenSSL requiere, p. ej., un engine PKCS#11 o la configuración p11tool/engine_pkcs11.

# Beispiel: OpenSSL mit engine_pkcs11 (vereinfacht)
openssl engine dynamic -pre SO_PATH:/usr/lib/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD

Errores habituales: IDs de slot/token incorrectas, tiempos de espera del PIN, ACL en el HSM. Pruebe de forma automatizada ciclos como los flujos de firma y de emisión antes de pasar a producción.

Revocación: CRL y OCSP en operación

La revocación es crítica: CRL (Certificate Revocation List) es una lista de números de serie revocados; los clientes la descargan periódicamente. OCSP permite la consulta en línea del estado de certificados individuales. Ambos tienen ventajas y desventajas:

• CRL: sencillo, escalable mediante CDN/HTTP, pero la lista puede ser grande y los clientes deben descargar actualizaciones periódicas.
• OCSP: estado en tiempo real, bajo volumen de datos por solicitud, pero requiere un OCSP responder fiable (alta disponibilidad) y respuestas firmadas (certificado del OCSP responder o OCSP stapling para TLS).

Para PKI internas suele ser apropiada una combinación: la CA emisora publica CRLs periódicamente (p. ej. cada 12 horas) y opera un OCSP responder para baja latencia y comprobaciones en línea reales.

Crear CRL con OpenSSL

# CRL erstellen (angenommen index.txt und serial vorhanden)
openssl ca -config openssl.cnf -gencrl -out crl.pem
# CRL in DER für HTTP-Distribution konvertieren
openssl crl -in crl.pem -outform DER -out crl.der

Importante: Webserver, CDN o servidores de archivos deben entregar las CRL con encabezados de caché consistentes. Compruebe si los clientes siguen correctamente la URL del CRL‑Distribution‑Point (CDP) del certificado.

Responder OCSP (ejemplo con OpenSSL)

# OCSP responder starten (vereinfacht, für Tests)
openssl ocsp -index index.txt -port 2560 -rsigner ocsp.cert.pem -rkey ocsp.key.pem -CA root.cert.pem -text

En producción utilice OCSP‑Responder especializados (p. ej. de CFSSL, EJBCA o appliances comerciales) y asegure alta disponibilidad (Load Balancer, Anycast). OCSP‑Stapling (registro TLS del estado OCSP) reduce las consultas desde el lado del cliente.

CFSSL: REST‑API y automatización

CFSSL ofrece APIs para solicitudes de firma y gestión de CRL/OCSP. Es habitual usar JSON‑Policies y un despliegue sencillo en Docker/Kubernetes. CFSSL es adecuado si desea integrar la emisión automatizada de certificados en pipelines CI/CD o en canalizaciones de aprovisionamiento.

{
  "signing":{
    "default":{
      "expiry":"8760h"
    },
    "profiles":{
      "server":{
        "expiry":"720h",
        "usages":["signing","key encipherment","server auth"]
      }
    }
  }
}

CFSSL es más sencillo de operar para REST‑Clients que jobs de scripts OpenSSL; preste atención a la autenticación de la API (mTLS, tokens) y a los límites de tasa, de lo contrario una cuenta comprometida puede generar certificados en masa.

Operación, monitorización y auditoría

Esenciales son los logs de auditoría (quién solicitó/aprobó un certificado), la monitorización (CA‑Service‑Health, tiempos de respuesta OCSP, estado de publicación de CRL), la copia de seguridad de las bases de datos de la CA (index.txt, serial) y pruebas periódicas de restauración. Configure alertas ante errores: publicaciones de CRL fallidas, OCSP‑Responder caído o errores de comunicación con el HSM.

Auditoría e integridad de logs

Integridad de logs significa: los logs deben ser verificables. Firme los logs de auditoría o almacénelos en modo append‑only en un servicio de logs externo. Sin logs verificables la reconstrucción en una respuesta a incidentes resulta problemática.

Solución de problemas: errores típicos

Aquí las causas más frecuentes y las secuencias de comprobación:

1. Fecha/hora incorrecta en el cliente: compruebe NTP; certificados caducados o NotBefore/NotAfter no válidos causan errores TLS.
2. CRL/OCSP inalcanzables: pruebe la URL CDP en el certificado y la URL OCSP; compruebe la accesibilidad HTTP(S) y el firewall.
3. PIN/ciclo de vida del HSM: bloqueo de PIN o bloqueo por autenticaciones fallidas; compruebe el estado del token y los logs del HSM.
4. Cadena faltante: el servidor entrega solo el certificado de entidad final, pero no la Sub‑CA; compruebe la configuración de la cadena TLS en servidores web o provisionadores.
5. Inconsistencias de formato: PEM vs DER; muchas herramientas esperan formatos explícitos.

Pasos de comprobación de ejemplo

# Prüfen des Zertifikatspfads und CRL/OCSP URLs
openssl x509 -in service.cert.pem -text -noout | sed -n '/X509v3 CRL/D, /Authority Information Access/ p'

# OCSP-Abfrage eines spezifischen Zertifikats (Testumgebung)
openssl ocsp -issuer subca.cert.pem -cert service.cert.pem -url http://ocsp.example.local:2560 -text -resp_text

Automatización y gestión del ciclo de vida

La automatización reduce los errores humanos al renovar/revocar. Para entornos internos existen dos enfoques típicos: CA interna compatible con ACME (p. ej. cfssl+acme‑bridge o soluciones tipo Boulder) o automatización basada en API mediante CFSSL/Vault. ACME es un protocolo que permite a los clientes solicitar y renovar certificados de forma automatizada; aquí es importante la autenticación de los clientes (HTTP‑01 interno, DNS‑01 o mTLS).

Aspectos importantes del ciclo de vida:

• Notificación automática antes del vencimiento (p. ej. 30/7/1 días).
• Renovación sin intervención (zero‑touch) para servidores y balanceadores de carga mediante hooks/agentes.
• Pruebas automáticas tras la renovación: verificar la cadena y OCSP‑stapling.

# Beispiel: Ansible Task (vereinfachte Darstellung) um CRL zu verteilen
- name: Upload CRL to webserver
  copy:
    src: /var/pki/crl/crl.der
    dest: /srv/www/ssl/crl/crl.der
    owner: root
    mode: '0644'
  notify: RESTart nginx

- name: RESTart nginx
  service:
    name: nginx
    state: RESTarted

Client‑Trust‑Verteilung und Bereitstellung

Es importante que todos los clientes y sistemas relevantes confíen en el Root y los intermediarios internos. Vías típicas de distribución:

• Windows: GPO distribuye el Root‑Cert en Trusted Root Certification Authorities.
• Linux/Servers: CA bundle central en /etc/pki/ca‑trust/source/anchors y ejecutar update‑ca‑trust.
• Móviles/puntos finales: MDM (Mobile Device Management) o instalación manual para dispositivos gestionados.

Pruebe el despliegue por fases y verifique si los clientes, tras la distribución, establecen correctamente conexiones TLS y comprueban OCSP/CRL.

Skalierung, Performance und Hochverfügbarkeit

El escalado afecta sobre todo a OCSP y la distribución de CRL. Los OCSP‑Responder deben ofrecer baja latencia; medidas habituales:

• Caché de OCSP (responder y balanceadores) y Anycast para distribución geográfica.
• CDN para la entrega de CRL con encabezados Cache‑Control adecuados y TTLs.
• Monitorización de tiempos de respuesta y tasas de error; failover automático del responder.

# Beispiel: Prometheus Alert (vereinfachtes Beispiel)
- alert: OCSPResponderDown
  expr: probe_success{job="ocsp_probe"} == 0
  for: 2m
  labels:
    severity: critical
  annotations:
    summary: "OCSP Responder nicht erreichbar"
    description: "OCSP Responder {{ $labels.instance }} antwortet nicht."

Disaster Recovery und Incident‑Runbook

Prepare un runbook claro para incidentes. Pasos importantes en caso de compromiso del Root/CA o fallo del HSM:

1. Aislar los sistemas afectados y preservar evidencias (logs). Documentar las marcas temporales.
2. Revocar certificados comprometidos y publicar inmediatamente una actualización de la CRL y el estado OCSP „revoked“.
3. Si el Root está comprometido: planificar cross‑signing o la reconstrucción de la PKI con un despliegue paralelo de nuevos Root/Sub‑CAs; informar a los equipos afectados.
4. Probar la RESTauración desde backup, incluyendo la importación HSM o procedimientos de HSM de sustitución.

Los ejercicios regulares de DR (al menos anuales) son obligatorios: pruebe los pasos de recuperación por escrito y realice una validación end‑to‑end.

Praktische Prüf‑Commands & Beispiele

Algunas comprobaciones útiles que debe integrar regularmente en sus runbooks:

# Verificación de la cadena de certificados
openssl verify -CAfile chain.pem service.cert.pem

# Descargar y verificar la CRL
curl -sS -o crl.der http://crl.example.local/crl.der
openssl crl -in crl.der -inform DER -text -noout

# Consulta OCSP de prueba a una URL de producción
openssl ocsp -issuer subca.cert.pem -cert service.cert.pem -url http://ocsp.example.local:2560 -header "HOST" "ocsp.example.local" -resp_text

# Estado del slot/token del HSM (pkcs11-tool)
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so -L
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so -T

Conclusión

Operar una PKI privada requiere más que emitir certificados: políticas claras, almacenamiento seguro de claves (idealmente HSM), automatización para emisión/renovación/revocación, monitorización y procedimientos de recuperación probados. OpenSSL ofrece control máximo; CFSSL facilita la automatización basada en API. CRL y OCSP se complementan en robustez y rapidez de respuesta. Pruebe los flujos de trabajo con HSM, verifique automáticamente la accesibilidad de CRL/OCSP y mantenga un runbook por escrito para rotación y respuesta a incidentes. Una PKI bien documentada minimiza los riesgos operativos y mantiene sus dependencias internas de TLS funcionando de forma fiable.

Recursos adicionales y enlaces internos

Para integraciones más profundas, revise la documentación de las herramientas: CFSSL, OpenSSL Engine PKCS#11, SoftHSM y las especificaciones del proveedor de HSM. Planifique además una auditoría de las políticas PKI y pruebas periódicas de RESTauración, de forma similar a las pruebas de recuperación de copias de seguridad en otros sistemas críticos.

Para este tema, OpenSSL PKI y la integración HSM también son importantes. La entrada contextualiza estos aspectos de forma clara y muestra en qué hay que centrarse en la práctica.