Certificados TLS de servidor
Tráfico web seguro a gran escala
Inventario de certificados
Descubrir y rastrear todos los certificados
Certificados DevOps
Automatizar para pipelines CI/CD
Cifrado de correo electrónico
S/MIME para correo electrónico empresarial
A medida que la vida útil de los certificados se reduce y la infraestructura se expande, la renovación manual ya no es viable. Los protocolos de automatización como ACME, SCEP, EST y CMP permiten que las máquinas gestionen la inscripción, la renovación y la revocación sin intervención humana.
Durante años, la gestión de certificados fue un proceso manual. Un administrador generaba un par de claves, enviaba una Solicitud de Firma de Certificado, esperaba la aprobación, descargaba el certificado, lo instalaba en el servidor y establecía un recordatorio en el calendario para volver a hacerlo antes de que expirara. Este enfoque funcionaba cuando las organizaciones gestionaban un puñado de certificados con una vida útil de uno o dos años.
Esa era ha terminado. La infraestructura moderna puede involucrar miles de certificados en entornos de nube, orquestadores de contenedores, flotas de IoT y arquitecturas de microservicios. Al mismo tiempo, la industria se está moviendo hacia ciclos de vida de certificados más cortos, con certificados de 90 días ya estándar para TLS público y ciclos de vida de 47 días en el horizonte. Cuando multiplicas miles de certificados por renovaciones cada pocas semanas, el cálculo es claro: la automatización no es opcional.
Afortunadamente, se han desarrollado varios protocolos específicamente para automatizar la inscripción, renovación y revocación de certificados. Cada protocolo fue diseñado para una era diferente y un conjunto distinto de casos de uso. Comprender sus fortalezas y limitaciones es esencial para elegir el enfoque correcto para su entorno.
El Entorno de Gestión Automática de Certificados (ACME) protocolo es el estándar de automatización más ampliamente adoptado para certificados TLS. Originalmente desarrollado por el Internet Security Research Group (ISRG) para Let's Encrypt, ACME se estandarizó como RFC 8555 en 2019 y desde entonces se ha convertido en el protocolo de facto para la emisión automatizada de certificados.
El cliente ACME se registra con la CA creando una cuenta y aceptando los términos del servicio. Esto establece un par de claves que autentica todas las solicitudes posteriores.
El cliente demuestra el control del dominio completando uno de varios tipos de desafío: HTTP-01 (colocando un archivo en el servidor web), DNS-01 (creando un registro DNS TXT) o TLS-ALPN-01 (respondiendo en la capa TLS). DNS-01 es particularmente útil para certificados comodín y sistemas internos.
Una vez verificado el desafío, el cliente envía una CSR y la CA emite el certificado. Todo el proceso, desde la solicitud hasta el certificado instalado, puede completarse en segundos sin ninguna interacción humana.
Los clientes ACME suelen estar configurados para comprobar la expiración del certificado y renovarlo automáticamente (a menudo a los dos tercios de la vida útil del certificado's). Esto elimina por completo el riesgo de olvidar una renovación.
Let's Encrypt hizo famoso a ACME al ofrecer certificados DV gratuitos y automatizados. Hoy, muchas CA empresariales también soportan ACME, permitiendo a las organizaciones usar el mismo protocolo tanto para certificados públicos como internos. Los clientes populares de ACME incluyen Certbot, acme.sh, Caddy (que tiene ACME incorporado) y cert-manager para Kubernetes.
El Protocolo Simple de Inscripción de Certificados (SCEP) es uno de los protocolos de automatización de certificados más antiguos, desarrollado originalmente por Cisco a finales de la década de 1990. A pesar de su antigüedad, SCEP sigue muy extendido, particularmente para inscribir dispositivos de red y equipos IoT que carecen de soporte para protocolos modernos.
Extremadamente amplio soporte de dispositivos. Enrutadores, conmutadores, firewalls, impresoras, plataformas de gestión de dispositivos móviles (MDM) y muchos sistemas heredados utilizan SCEP de forma nativa. Utiliza operaciones HTTP GET/POST simples, lo que lo hace compatible con entornos restringidos.
SCEP nunca se estandarizó formalmente como un RFC (permanece como un borrador de Internet). Depende de un secreto compartido (contraseña de desafío) para la autenticación inicial, lo que plantea riesgos de seguridad si se intercepta. SCEP también carece de soporte nativo para la renovación de certificados; los dispositivos normalmente necesitan volver a inscribirse desde cero.
A pesar de sus limitaciones, SCEP suele ser la única opción para infraestructuras heredadas. Las organizaciones que necesitan soportar tanto dispositivos modernos como heredados frecuentemente ejecutan SCEP junto a protocolos más nuevos.
Inscripción a través de Transporte Seguro (EST), definido en RFC 7030, fue diseñado como el reemplazo moderno de SCEP. Aborda muchas de las vulnerabilidades de seguridad de SCEP's mientras proporciona una arquitectura más limpia y extensible para la inscripción de certificados.
Todas las operaciones EST se ejecutan sobre HTTPS (TLS), lo que significa que el canal de inscripción está encriptado y autenticado. Esto elimina la vulnerabilidad de la contraseña de desafío que afecta a SCEP y proporciona una base de seguridad mucho más fuerte.
A diferencia de SCEP, EST tiene un punto de reinscripción dedicado. Un dispositivo puede usar su certificado existente para autenticarse y solicitar uno nuevo, lo que permite una rotación de certificados sin problemas sin secretos compartidos ni intervención manual.
EST admite varios métodos de autenticación: certificados de cliente existentes, autenticación HTTP Basic/Digest, o una combinación. Esta flexibilidad lo hace adecuado tanto para el arranque inicial como para la renovación continua en entornos diversos.
EST se adopta cada vez más en entornos empresariales, especialmente para la identidad de dispositivos y casos de uso de PKI interna. Es el protocolo recomendado para nuevas implementaciones donde no se requiere compatibilidad con SCEP.
El Protocolo de Gestión de Certificados (CMP), definido en RFC 4210 (con actualizaciones en RFC 9480 y RFC 9483), es el más completo de los cuatro protocolos. CMP fue diseñado para soportar el ciclo completo ciclo de vida del certificado, desde la solicitud inicial hasta la renovación, actualización, revocación e incluso la recuperación de claves.
CMP cubre la inscripción, la re‑generación de claves, la renovación, la revocación y la certificación cruzada. Ningún otro protocolo gestiona tantas operaciones del ciclo de vida de forma nativa.
CMP puede operar sobre HTTP, HTTPS o incluso directamente sobre TCP. Esto lo hace adaptable a entornos donde la terminación TLS se gestiona de manera diferente o donde se necesitan transportes ligeros.
CMP incluye funciones como generación central de claves, prueba de posesión y manejo detallado de errores, que son esenciales para industrias reguladas como telecomunicaciones, automotriz e IoT industrial.
CMP's comprehensiveness comes at a cost. The protocol is significantly more complex to implement and configure than ACME or EST, which limits its adoption to organizations that truly need its advanced capabilities.
CMP es particularmente prevalente en la industria de telecomunicaciones (las normas 3GPP lo hacen referencia) y en entornos industriales donde los dispositivos necesitan realizar actualizaciones de claves y renovaciones de certificados en redes limitadas.
Ningún protocolo es el mejor para cada escenario. La elección correcta depende de sus dispositivos, su infraestructura de CA y del nivel de automatización del ciclo de vida que necesita. Aquí se muestra cómo se comparan:
| ACME | SCEP | EST | CMP | |
|---|---|---|---|---|
| Estándar | RFC 8555 | Borrador de Internet | RFC 7030 | RFC 4210 |
| Mejor para | Servidores web, TLS | Dispositivos heredados, MDM | Dispositivos modernos, IoT | Telecomunicaciones, industrial |
| Transporte | HTTPS | HTTP | HTTPS | HTTP, HTTPS, TCP |
| Renovación | Automático | Reinscripción | Reinscripción nativa | Renovación nativa |
| Complejidad | Baja | Baja | Media | Alta |
| Revocación | Soportado | No soportado | No nativo | Nativo |
En la práctica, la mayoría de las organizaciones terminan soportando múltiples protocolos. ACME gestiona certificados de servidores web, SCEP cubre equipos de red heredados, EST administra la inscripción de dispositivos modernos, y CMP sirve casos de uso industriales especializados. La clave es tener una inventario centralizado que rastrea los certificados sin importar qué protocolo los emitió.
Soporte multiprotocolo: Evertrust PKI admite de forma nativa ACME, SCEP, EST y CMP, brindándole una plataforma CA única que soporta todos los protocolos que su infraestructura necesita. No se requieren servidores o pasarelas separados.
Seguimiento unificado del ciclo de vida: Evertrust CLM rastrea cada certificado sin importar el protocolo, la CA o el entorno. Ya sea que un certificado se haya emitido a través de ACME, inscrito mediante SCEP o provisionado mediante CMP, aparece en el mismo inventario con la misma monitorización y alerta.
Aplicación de políticas en la inscripción: La automatización no significa perder el control. Evertrust aplica las políticas de certificados de su organización en el punto de emisión, asegurando que las solicitudes automatizadas aún cumplan con los requisitos de algoritmo clave, validez y nomenclatura.
Listo para ciclos de vida más cortos: Con soporte nativo de ACME y flujos de trabajo de automatización continuos, Evertrust garantiza que su infraestructura esté preparada para el cambio a ciclos de vida de certificados de 90 y 47 días sin aumentar la carga operativa.
