Sovereign Certificate Authority

Sovereign Certificate Authority es una autoridad de certificación interna que traslada 1:1 la experiencia Let’s Encrypt a tu propia red: protocolo ACME, enrolment automático de certificados, renovación automática — para todos los servicios internos, subdominios y dispositivos de empleados. En producción activa.

  flowchart LR
    A[Servicio interno] -->|Petición ACME| B[Sovereign CA]
    B -->|challenge| C[HTTP-01 / DNS-01]
    C -->|OK| D[Emitir cert. 90 días]
    D --> A
    A -.->|renovar a los 60 días| B

De qué se trata

Toda organización con servicios internos — del wiki al tracker de incidencias hasta los dashboards de monitorización — conoce el juego: certificados TLS. Tres opciones clásicas, ninguna es buena:

1. Certificados autofirmados — Cada navegador alerta, los usuarios saltan los avisos (cultura de seguridad rota), y llega un punto en que un clic de phishing es indistinguible del tráfico normal.
2. Certificados de CA pública para hostnames internos — de pago (150–500 € por certificado y año), y todos los hostnames internos acaban en los Certificate Transparency logs públicos — un atacante puede leer exactamente qué sistemas internos existen.
3. Let’s Encrypt — gratuito, pero no funciona para hosts puramente intranet (no hay accesibilidad pública para la validación HTTP), y con 50 certificados por semana por dominio sus rate limits son estrictos.

La Sovereign Certificate Authority es la respuesta: el mismo confort que Let’s Encrypt, pero interno, sin exposición a logs públicos y sin límites.

La experiencia Let’s Encrypt — interna

Cada cliente compatible con ACME funciona directamente con la CA interna — sin cambios de código, sin herramientas especiales, sin API propietaria.

• 🤖 Auto-enrolment — Un servicio solo necesita conocer el endpoint ACME de la CA interna; a partir de ahí obtiene su certificado por sí mismo.
• 🔁 Renovación automática — Duración por defecto 90 días, renovación automática a los 60 días. Nadie tiene que pensar en fechas de caducidad.
• 🌐 Reto HTTP-01 + DNS-01 — Ambos métodos de validación estándar, según el caso de uso.
• 🃏 Comodines — Certificados wildcard para espacios de subdominios completos (*.intern.example.com).
• 📜 Clientes estándar — certbot, acme.sh, lego, dehydrated, Caddy, Traefik, nginx-acme — todos funcionan sin adaptación.

¿Por qué no usar simplemente Let’s Encrypt?

El punto decisivo: exposición en CT logs. Cada certificado emitido por una CA pública — incluido Let’s Encrypt — acaba en un log público, buscable. Cualquiera que consulte crt.sh ve todos tus hostnames internos. Las herramientas de reconnaissance de atacantes aprovechan exactamente eso.

Una CA interna emite certificados sin que aparezcan en ningún sitio público. Los hostnames internos siguen siendo internos.

Funcionalidades operativas

• 🌳 Jerarquía PKI multi-nivel — CA raíz offline, CA intermedia online para la emisión ACME. Práctica PKI estándar.
• 🔄 Revocación automática — Endpoints CRL y OCSP para listas de revocación; certificados comprometidos o retirados se revocan limpiamente.
• 🔐 Clave hardware opcional — La clave intermedia puede mantenerse en un HSM o TPM — incluso con servidor comprometido, la clave de CA no queda expuesta.
• 📊 Monitorización e inventario — Vista general de cada certificado emitido, fechas de caducidad, hosts afectados.
• 🎯 Motor de políticas — ¿Qué cliente puede emitir qué certificados? Vinculación de cuentas, allowlists de dominios, límites máximos de validez por rol.
• 🔌 Integración con servicios — Certificados de túnel (VPN, mTLS), service mesh (compatible Envoy/Istio), servidores de correo (SMTP/IMAP TLS), reverse proxies, dispositivos IoT.
• ⏰ Configuración de vida útil — Vidas útiles cortas (24 h para pipelines, 90 días para servicios, 1 año para IoT) — ajustable a grano fino por caso de uso.
• 🔍 Log de auditoría — Cada emisión, renovación y revocación se registra de forma estructurada.

Casos de uso típicos

• 🏢 Aplicaciones web internas — Wiki, tracker, CRM, dashboards con certificados TLS reales que todos los navegadores aceptan (tras instalar la raíz en los endpoints).
• 🤝 mTLS servicio a servicio — Microservicios / service mesh con autenticación mutua en lugar de claves API.
• 📱 Autenticación de dispositivos — Portátiles y dispositivos móviles de empleados reciben certificados de cliente para acceso a Wi-Fi, VPN y servicios.
• 📧 Infraestructura de correo — Envío SMTP, IMAP/POP con certificados válidos sin pagar a CA pública.
• 🛠️ Pipelines CI/CD — Certificados de corta vida para runners de build, emitidos automáticamente y desechados tras el trabajo.
• 🌍 Dominios DNS internos — .internal, .lan, subdominios top-level propios — certificados donde Let’s Encrypt por definición no puede emitir.

Por qué esto es un tema de CEO

• 💰 Evitación de coste — Por 100 servicios internos con certificados de CA pública: típicamente 30 000–50 000 € al año. Con una CA interna: 0 €.
• 🔍 Protección contra reconnaissance — Los hostnames internos son hoy la mayor fuga en reconnaissance previa al ataque — entregan a los atacantes un mapa de la organización. Una CA interna elimina por completo esta fuga.
• 🛡️ Soberanía — Control total sobre la cadena de confianza. Sin dependencia de CAs externas cuyo root program puede cambiar o cuya confianza puede ser revocada (Symantec, DarkMatter, …).
• 📋 Cumplimiento — Cadena de custodia completa. En sectores regulados (finanzas, salud, defensa) las CAs internas son a menudo obligatorias.
• ♻️ Continuidad de negocio — Si la CA externa no está disponible (mantenimiento, sanciones, insolvencia), los certificados internos pueden seguir emitiéndose.
• 🔧 Escalado sin coste marginal — 10 o 10 000 certificados — el esfuerzo y el coste son prácticamente los mismos.

Base tecnológica

Construida sobre implementaciones de CA open source probadas con soporte completo del protocolo ACME.

Sovereign Certificate Authority — variante interna de Let’s Encrypt · ACME RFC 8555 · enrolment totalmente automatizado · sin exposición a CT logs públicos · en producción