NOTICIAS DE ÚLTIMA HORA
¿Qué es el Fidget Spinner y por qué todos quieren uno?
Google ofrece nuevos cursos virtuales gratuitos con certificado
¿Cuáles serán las novedades del iPhone 8?
6 formas para agilizar tu mente
6 simples hábitos para mantener tu buena salud
Automated Certificate Management Environment

Summary

El Automatic Certificate Management Environment (ACME) es un protocolo de comunicaciones para automatizar las interacciones entre las autoridades de certificación y los servidores de los usuarios, permitiendo el despliegue automatizado de infraestructuras de clave pública a muy bajo coste.[1]​[2]​ Fue diseñado por el Internet Security Research Group (ISRG) para su servicio Let's Encrypt.[1]​

ACME logo

El protocolo, basado en el intercambio de mensajes en formato JSON a través de HTTPS, ha sido publicado como un Estándar de Internet en el RFC 8555[3]​ por su propio grupo de trabajo del IETF.[4]​

Implementaciones de clientes

editar

El ISRG proporciona implementaciones de referencia gratuitas y de código abierto para ACME: certbot es una implementación en Python del software de gestión de certificados de servidor que utiliza el protocolo ACME,[5]​[6]​[7]​ y boulder es una implementación de autoridad de certificación escrita en Go.[8]​

Desde 2015, ha aparecido una gran variedad de opciones de clientes para todos los sistemas operativos.[9]​

Versiones de la API

editar

API Versión 1

editar

La especificación de la API v1 fue publicada el 12 de abril de 2016. Permite la emisión de certificados para nombres de dominio completamente cualificados, como example.com o cluster.example.com, pero no para comodines como *.example.com. Let's Encrypt desactivó el soporte para la API v1 el 1 de junio de 2021.[10]​

API Versión 2

editar

La API v2 fue lanzada el 13 de marzo de 2018 tras varios retrasos. ACME v2 no es compatible hacia atrás con la v1. La versión 2 admite dominios comodín, como *.example.com, lo que permite que muchos subdominios tengan TLS confiable, por ejemplo: https://cluster01.example.com, https://cluster02.example.com, https://example.com, en redes privadas bajo un solo dominio usando un único certificado "comodín" compartido.[11]​

Un nuevo requisito importante en la v2 es que las solicitudes para certificados comodín requieren la modificación de un registro TXT del sistema de nombres de dominio (DNS), verificando el control sobre el dominio.

Los cambios en el protocolo ACME v2 respecto a la v1 incluyen:[12]​

  • Ha cambiado el flujo de autorización/emisión.
  • Ha cambiado la autorización de solicitudes JWS.
  • El campo "resource" en los cuerpos de las solicitudes JWS ha sido reemplazado por una nueva cabecera JWS: "url".
  • Renombramiento de recursos/puntos finales del directorio.
  • Cambio de URI → URL en los recursos de desafíos.
  • La creación de cuenta y la aceptación de los Términos de Servicio se combinan en un solo paso. Anteriormente, eran dos pasos separados.
  • Se implementó un nuevo tipo de desafío, TLS-ALPN-01. Dos tipos de desafío anteriores, TLS-SNI-01 y TLS-SNI-02, fueron eliminados por problemas de seguridad.[13]​[14]​

Casos de uso comunes

editar
  • Automatización de certificados web (Web TLS Automation): Uso más extendido, típicamente con Let's Encrypt para HTTPS gratuito en servidores web como Apache o Nginx.
  • IoT y dispositivos embebidos (IoT Certificate Provisioning): Algunos dispositivos usan ACME para aprovisionar certificados automáticamente y cifrar sus comunicaciones.
  • Entornos DevOps y CI/CD (DevOps Automation): ACME permite rotación automática de certificados en pipelines de despliegue sin intervención manual.
  • Servicios internos (Internal Services with Private PKI): A través de autoridades de certificación internas compatibles con ACME, es posible asegurar servicios internos sin depender de CA públicas.

Seguridad y vulnerabilidades

editar

Aunque ACME ha simplificado la gestión de certificados, su uso conlleva ciertos riesgos de seguridad que deben conocerse:

  • Authorization Cache Attack: Un atacante que compromete una cuenta ACME puede reutilizar autorizaciones previamente validadas para emitir nuevos certificados sin revalidación.[15]​
    • Mitigación: Emplear extensiones como ACME++, que vinculan la solicitud a la IP y cliente específico, forzando una validación en cada solicitud.
  • Cross-Site Scripting in HTTP-01 Challenge: En implementaciones inseguras del desafío HTTP-01, es posible introducir scripts maliciosos en respuestas HTTP.[16]​
    • Mitigación: Validar y sanear correctamente las respuestas HTTP. Usar HTTPS siempre que sea posible.
  • Enterprise ACME Integration Limitations: Algunas soluciones empresariales no admiten ACME fuera de Let's Encrypt, dificultando su adopción en infraestructuras privadas.[17]​
    • Mitigación: Utilizar servidores ACME privados, que permitan control y personalización.
  • Wildcard Certificate Automation Issues: El desafío DNS-01, necesario para certificados comodín, puede complicarse en entornos sin automatización DNS.[18]​
    • Mitigación: Integrar proveedores DNS compatibles con APIs o herramientas como lego, certbot-dns-<provider>, o soluciones CI/CD para gestionar los registros TXT automáticamente.

Véase también

editar

Simple Certificate Enrollment Protocol (SCEP), un intento previo de protocolo de despliegue automático de certificados.

Referencias

editar
  1. ↑ a b Steven J. Vaughan-Nichols (9 de abril de 2015). «Securing the web once and for all: The Let's Encrypt Project». ZDNet. 
  2. ↑ sh. «ietf-wg-acme/acme-spec». GitHub. Consultado el 5 de abril de 2017. 
  3. ↑ Automatic Certificate Management Environment (ACME), doi:10.17487/RFC8555, RFC 8555 .
  4. ↑ «Automated Certificate Management Environment (acme)». IETF Datatracker. Consultado el 12 de marzo de 2019. 
  5. ↑ «Certbot». EFF. Consultado el 14 de agosto de 2016. 
  6. ↑ «certbot/certbot». GitHub. Consultado el 2 de junio de 2016. 
  7. ↑ «Announcing Certbot: EFF's Client for Let's Encrypt». LWN. 13 de mayo de 2016. Consultado el 2 de junio de 2016. 
  8. ↑ «letsencrypt/boulder». GitHub. Consultado el 22 de junio de 2015. 
  9. ↑ «ACME Client Implementations - Let's Encrypt - Free SSL/TLS Certificates». letsencrypt.org. 20 de febrero de 2025. 
  10. ↑ «End of Life Plan for ACMEv1 - API Announcements». Let's Encrypt Community Support. 5 de mayo de 2021. Consultado el 12 de junio de 2021. 
  11. ↑ «ACME v2 API Endpoint Coming January 2018 - Let's Encrypt - Free SSL/TLS Certificates». letsencrypt.org. 14 de junio de 2017. 
  12. ↑ «Staging endpoint for ACME v2». Let's Encrypt Community Support. 5 de enero de 2018. 
  13. ↑ «Challenge Types - Let's Encrypt Documentation». Let's Encrypt. 8 de diciembre de 2020. Consultado el 12 de mayo de 2021. 
  14. ↑ Automatic Certificate Management Environment (ACME), doi:10.17487/RFC8555, RFC 8555 .
  15. ↑ Tianyu Zhang, Zhang Han, Yunze Wei, Yahui Li, Xingang Shi, Jilong Wang, Xia Yin (29 Jan 2025). «ACME++: Secure ACME Client Verification for Web-PKI». openreview. 
  16. ↑ James Walker (5 de septiembre de 2018). «Reflected response: Dangerous ACME implementations result in XSS». portswigger. 
  17. ↑ Carl Tashian (25 de mayo de 2025). «The Embarrassing State of Enterprise ACME Support». smallstep. 
  18. ↑ Let’s Encrypt Team (7 de enero de 2025). «EFF, Others Plan to Make Encrypting the Web Easier in 2015». letsencrypt. 

Enlaces externos

editar
  • Barnes, Richard; Hoffman-Andrews, Jacob; Kasten, James (March 2019). «Automatic Certificate Management Environment (ACME)». IETF. 
  • Automatic Certificate Management Environment (ACME) RFC 8555.
  • List of ACME clients, Let's Encrypt
  • List of commonly used ACME clients, acmeclients.com

Al usar esta plataforma, usted acepta el Términos de Uso ©2020 Knowpia