Let’s Encrypt ACME: automatizar los certificados y gestionar las renovaciones de forma segura

Procedimiento ACME y funciones de clave separadas

ACME estandariza la comunicación entre un cliente y la autoridad de certificación, no todo el entorno operativo. El cliente utiliza en primer lugar una cuenta ACME y, a continuación, crea un pedido para uno o varios nombres de dominio. El servidor solicita una autorización para cada identificador. Solo cuando esta se ha completado con éxito, el cliente puede finalizar el pedido con una solicitud de firma de certificado (CSR, por sus siglas en inglés) y obtener el certificado emitido.

1. Genera una clave de cuenta o utiliza una cuenta ACME ya existente y crea la orden.
2. Para cada identificador solicitado, proporcionar el desafío especificado y esperar a que se complete la autorización.
3. Generar un par de claves independiente para el certificado, crear la CSR a partir de él y finalizar el pedido. La clave pública de la CSR no debe coincidir con la clave de la cuenta que autentifica la orden de finalización.
4. Recuperar el certificado y la cadena de certificados, almacenarlos de forma segura y distribuirlos a los puntos finales TLS previstos.

El Clave de cuenta ACME autentica al cliente para la cuenta ante el servidor ACME y firma los mensajes del protocolo. La clave privada utilizada en la CSR, por el contrario, pertenece a la identidad TLS posterior. La RFC 8555 exige dos clases de claves diferentes: la clave pública de la CSR no debe corresponder a ninguna clave de cuenta conocida y, en particular, no debe ser idéntica a la clave de cuenta que autentica la orden de finalización. Tanto el cliente como el servidor deben verificar esta separación.

En el caso de DNS-01, se añade un tercer componente sensible: la autorización para la API de DNS. Let’s Encrypt señala que disponer de las credenciales completas de la API de DNS en un servidor web aumenta considerablemente las consecuencias de un ataque. Por lo tanto, como medida de seguridad operativa, el token debería estar autorizado, en la medida de lo posible, únicamente a modificar los registros de desafío necesarios; como alternativa, la validación del DNS puede realizarse en un sistema independiente.

Las claves de cuenta, las claves de certificado y el acceso al DNS constituyen distintos ámbitos de confianza. El uso de pares de claves diferentes para la cuenta y el certificado es un requisito del protocolo; además, su almacenamiento separado, los derechos de acceso estrictamente limitados y los procesos de rotación independientes son medidas operativas importantes. De este modo, el hecho de que un token de DNS se vea comprometido no implica necesariamente que se tenga acceso ni a la clave privada del certificado ni a la cuenta ACME.

La automatización no elimina los requisitos previos erróneos. Un puerto inaccesible, un enrutamiento incorrecto, una delegación de DNS inadecuada o unos derechos de acceso excesivos siguen siendo problemas operativos, incluso si la creación de órdenes está automatizada. ACME agiliza el proceso repetible; los operadores deben implementar de forma fiable en su entorno un modelo de derechos, la separación obligatoria entre las claves de la cuenta y las del certificado, un almacenamiento seguro y el control de los certificados realmente entregados.

El reto adecuado para la infraestructura

El «Challenge» determina cómo una autoridad de certificación verifica el control sobre un identificador. Por lo tanto, debería derivarse de la ruta de red, la gestión del DNS y la terminación TLS, y no de una preferencia general por una herramienta de cliente. HTTP-01, DNS-01 y TLS-ALPN-01 establecen diferentes tipos de control y, en consecuencia, plantean distintos requisitos en cuanto a infraestructura y autorizaciones.

En el caso de una única página web accesible al público, es HTTP-01 suele ser la forma más directa. El cliente pone a disposición un recurso en /.well-known/acme-challenge/ listo, que accede a Let’s Encrypt a través del puerto 80. Si un dominio apunta a varios destinos A o AAAA, este recurso debe estar accesible en todos los sistemas a los que pueda llegar la solicitud de validación. De lo contrario, se producirá un error de validación que solo se manifestará ocasionalmente.

Certificados comodín para *.example.org por el contrario, exigen obligatoriamente DNS-01. Para ello, el cliente publica un registro TXT en _acme-challenge.example.org. Esto resulta adecuado para muchos subdominios dinámicos, servidores web distribuidos o un equilibrador de carga, ya que ninguna instancia HTTP concreta tiene que entregar el archivo de validación. Sin embargo, es imprescindible que el cambio en el DNS sea fiable y se pueda automatizar.

Un proxy inverso que no pueda utilizar el puerto 80 puede TLS-ALPN-01 utilizarse siempre que controle la terminación TLS en el puerto 443 y el cliente utilizado sea compatible con este desafío. La validación se lleva a cabo a través de una conexión TLS específica, no mediante un archivo web normal. Por lo tanto, este procedimiento resulta especialmente adecuado para infraestructuras especializadas de proxy o de alojamiento, pero no como sustituto general de HTTP-01. Tampoco en este caso se admiten los comodines.

Ningún método es superior en general: HTTP-01 reduce el acceso al DNS en un sitio web sencillo; DNS-01 permite el uso de comodines y desacopla la validación de la ruta web; TLS-ALPN-01 aprovecha de forma específica los controles TLS existentes. Lo fundamental es que el desafío elegido funcione en rutas reales de conmutación por error, IPv4 e IPv6, y que sus permisos se ajusten al modelo operativo correspondiente.

ARI, perfiles y plazos más cortos

Con Información sobre la renovación de ACME (ARI) la lógica de renovación pasa de una fecha límite establecida localmente a un intervalo de tiempo recomendado por el servidor ACME. El cliente solicita esta información para un certificado existente y elige un momento aleatorio dentro de ese intervalo. De este modo, las renovaciones pueden distribuirse en el tiempo y, en caso de acontecimientos especiales, adelantarse de forma selectiva.

ARI es una extensión estandarizada, pero no es una característica automática de todos los clientes o paneles de alojamiento instalados. Let’s Encrypt puede ofrecer nuevas funciones ACME compatibles con versiones anteriores en el punto final existente; que una instalación concreta las utilice depende de su versión y de su implementación. Por lo tanto, en el caso de grandes parques de servidores, hay que comprobar si el cliente consulta ARI, respeta el intervalo de tiempo y no vuelve a sincronizar las renovaciones.

Además, Let’s Encrypt asigna perfiles de certificado a los pedidos. Si no se selecciona ningún perfil de forma expresa, el perfil clásico es el predeterminado y, actualmente, tiene una validez de 90 días. El perfil tlsserver Tiene una vigencia de 45 días, plazos más cortos para las autorizaciones y órdenes pendientes, y un máximo de 25 nombres DNS. shortlived También utiliza tiempos de vida cortos para los objetos, tiene una validez de unas 160 horas y admite identificadores DNS e IP.

La selección de perfiles también requiere que el cliente sea compatible; no debe deducirse únicamente a partir de la documentación del servidor. Los perfiles se diferencian, además de por su periodo de validez y sus identificadores, en otras características. Por lo tanto, ni las aplicaciones ni las herramientas de inventario deben dar por sentado tácitamente un proceso uniforme ni la presencia de un «nombre común» en cada certificado.

Desde el punto de vista matemático, entre 90 días y unas 160 horas hay un factor de aproximadamente 13,5 en la duración. De ello no se deriva ninguna carga cuantificable, sino una consecuencia clara para la planificación: cualquier incidencia en el pedido, la distribución o la recarga se traduce en certificados de corta duración mucho antes. Solo tienen sentido para sistemas cuya cadena de suministro completa esté supervisada y cuya renovación no dependa de intervenciones manuales. Para las renovaciones coordinadas por ARI, Let’s Encrypt aplica normas especiales sobre límites de solicitudes bajo condiciones documentadas.

Matriz de retos y delegación segura de DNS

La elección del reto se basa en la infraestructura disponible, no en una clasificación general. HTTP-01 requiere una respuesta accesible públicamente a través del puerto 80, DNS-01 una entrada TXT controlable y TLS-ALPN-01 el control sobre la terminación TLS en el puerto 443. Los nombres comodín solo se pueden validar con DNS-01.

Por lo tanto, un sitio web con un único servidor web suele funcionar bien con HTTP-01. Sin embargo, si los registros A o AAAA del DNS apuntan a varios sistemas, cada destino al que se acceda realmente debe proporcionar el recurso esperado. De lo contrario, el resultado dependerá del punto final al que llegue la validación. Un equilibrador de carga o un almacén de retos sincronizado de forma centralizada solo resuelve este problema si cubre todas las rutas.

Para el DNS-01, se utiliza como Autorización mínima Se debe intentar que el cliente ACME solo pueda modificar las entradas de desafío necesarias. La restricción que realmente sea posible depende de la API y del modelo de permisos del proveedor de DNS; no todos los servicios permiten conceder derechos sobre un único nombre TXT. Si solo se dispone de un acceso de amplio alcance, la validación debería trasladarse a un sistema independiente o delegarse en una zona de desafío específica. Los datos de acceso deben almacenarse en un repositorio protegido, separados de los certificados y de las claves de la cuenta ACME.

En el caso de zonas extensas, una zona de desafío independiente puede restringir aún más los derechos. La delegación de _acme-challenge Mediante CNAME o NS, los datos de validación se trasladan a un dominio de administración propio. De este modo, el cliente solo tendrá derechos de modificación en ese dominio. Antes de la puesta en producción, es necesario comprobar el contenido del registro TXT y la resolución DNS: no basta con una respuesta correcta de la API si los resolutores aún no ven la delegación o el registro.

Automatizar de forma fiable la renovación y la distribución

Resistente Gestión de certificados no termina con la obtención de un certificado. En un entorno distribuido, un trabajador ACME central inicia la validación y almacena de forma segura tanto el certificado como la clave privada. Solo después se distribuyen los artefactos a los puntos finales TLS, donde se verifican y se activan de forma controlada. La clave del certificado utilizada en la CSR debe ser distinta de la clave de la cuenta ACME utilizada para la autenticación; en el plan operativo debe especificarse cómo se almacenarán, autorizarán y rotarán posteriormente ambas claves por separado.

La siguiente tabla describe un modelo operativo recomendado para la cadena de suministro. La RFC 8555 exige que la clave pública de la CSR no se corresponda con ninguna clave de cuenta conocida y, en particular, que no coincida con la clave de cuenta utilizada para autenticar la orden de finalización. La separación organizativa concreta entre el almacenamiento, los derechos de acceso y la rotación se basa en este requisito del protocolo. El «deploy hook» de Certbot está previsto para acciones posteriores a la emisión satisfactoria. La seguridad de la transmisión, la verificación del destino y la comprobación externa de TLS deben adaptarse a la infraestructura correspondiente.

A la hora de realizar cambios en las integraciones de Panel o DNS, no se debe considerar la cadena de producción como un sistema independiente. Especialmente cuando la gestión se realiza a través de Actualizaciones de Plesk para proveedores de alojamiento web Las funciones disponibles dependen del soporte del panel, de las ampliaciones y de los servicios conectados. La capacidad concreta del cliente ACME, por ejemplo, para ampliaciones de protocolo adicionales, también depende de la versión y debe comprobarse en la combinación utilizada.

En Certbot, un «deploy hook» puede activar el último paso, ya que solo se ejecuta tras una renovación satisfactoria. El siguiente ejemplo da por hecho que la ruta local es un script ejecutable y verificado que no contiene datos de acceso. El script debería idempotente trabajar, registrar los errores y recargar únicamente aquellos servicios que utilicen el certificado actualizado.

certbot renew --deploy-hook /usr/local/sbin/reload-tls-services

El código de salida de certbot renew no es prueba de que haya un nuevo certificado: aunque no hubiera nada que renovar, el comando puede terminar con el estado 0. Por lo tanto, el sistema de supervisión debe determinar de forma independiente qué certificado emite realmente el punto final público, cuándo caduca y si la recarga se ha realizado con éxito.

CAA, perfiles y certificados para direcciones IP

Un registro CAA es un Barandilla de exposición: Establece qué entidades de certificación pueden emitir certificados para un dominio. Además, la directiva puede especificar el método de validación permitido y, mediante el parámetro accounturi Establecer la cuenta ACME prevista. La clave de cuenta actual autentifica el acceso a esta cuenta, aunque puede modificarse mediante el proceso de cambio de clave ACME. Por lo tanto, la vinculación de la cuenta no sustituye ni a la protección que ofrece la clave de cuenta actual ni a un sistema de permisos completo.

La siguiente línea de registro permite el uso de Let’s Encrypt para el dominio únicamente mediante la validación DNS-01. Solo es válida si la validación DNS-01 se ha configurado de forma automatizada y la zona de desafío se gestiona de forma fiable. Quien desee utilizar posteriormente HTTP-01 para un sitio web concreto o TLS-ALPN-01 para un proxy inverso, bloqueará deliberadamente esta emisión con la restricción indicada.

example.org. CAA 0 issue "letsencrypt.org;validationmethods=dns-01"

Una sola línea no describe necesariamente la totalidad de Política de la CAA de la zona. Varios registros del mismo tipo tienen un efecto acumulativo: si uno de ellos permite la emisión, dicha autorización puede mantenerse a pesar de que haya otros registros con restricciones más estrictas. En el caso de los certificados comodín, además, hay que comprobar si issuewild-Hay registros disponibles. Si no hay dichos registros, se aplica issue también para los comodines; existentes issuewild-Las entradas, por el contrario, controlan la emisión de comodines de forma independiente. Por lo tanto, lo que siempre es determinante es el conjunto completo de registros válidos asociados al nombre comprobado.

Los certificados para direcciones IP públicas son un caso distinto al de los certificados de dominio. Let’s Encrypt admite identificadores de IP en el perfil shortlived; como métodos de validación se pueden utilizar HTTP-01 y TLS-ALPN-01. DNS-01 no puede validar direcciones IP. Por lo tanto, su breve periodo de validez, de unas 160 horas, requiere una renovación, distribución y control de entrega automatizados y continuos.

Por lo tanto, el perfil «shortlived» solo es adecuado para interfaces a las que se puede acceder directamente por IP si cada paso funciona sin necesidad de intervenciones manuales. No se trata de una variante simplificada para sistemas que se mantienen de forma ocasional. Además, tanto el cliente ACME utilizado como el entorno de destino deben ser compatibles con el perfil elegido y con el «challenge» seleccionado; el hecho de que esté disponible en el servicio ACME no garantiza que todas las versiones del cliente lo admitan.

Supervisión y resolución de errores, primero en el entorno de pruebas

La resolución de problemas con ACME comienza por el método de validación que se utilice realmente, no por solicitar un nuevo certificado. Para realizar cambios en el cliente, el enrutamiento, el cortafuegos o el DNS, es recomendable utilizar el punto de conexión de prueba independiente de Let’s Encrypt. El entorno de prueba tiene sus propios límites, considerablemente más altos, pero no es ilimitado; los certificados de prueba emitidos allí no son de confianza pública. Aunque las nuevas funciones de protocolo pueden estar disponibles en el punto de acceso ACME, es necesario comprobar por separado si el cliente instalado las admite.

En el caso de HTTP-01, lo primero que hay que comprobar es si se puede acceder públicamente al dominio en cuestión a través del puerto 80 y si el archivo solicitado se encuentra en /.well-known/acme-challenge/ en el sistema de destino. La presencia de varios registros A o AAAA complica la prueba: cada punto final al que se pueda acceder realmente debe proporcionar el archivo de desafío correspondiente. Las causas más habituales son un enrutamiento de host virtual incorrecto, un proxy intercalado, una regla de cortafuegos o contenedores no sincronizados.

Por el contrario, TLS-ALPN-01 exige el control sobre la terminación TLS en el puerto 443. En caso de error, se debe comprobar qué equilibrador de carga o proxy acepta la conexión, si proporciona el certificado necesario para el desafío y si un servicio TLS habitual anula el proceso. El hecho de que se haya generado correctamente un archivo de certificado local no garantiza que el punto final al que se accede públicamente lo utilice.

En DNS-01, el nombre y el contenido del registro TXT se encuentran en _acme-challenge controlarse por separado. El registro debe estar publicado en la zona delegada o de referencia; además, la cadena de delegación debe ser correcta si se utiliza una zona de desafío independiente. Los intentos fallidos repetidos debido a errores tipográficos, cambios que aún no son visibles o una delegación incorrecta deben analizarse primero en el entorno de prueba.

Eficaz Monitoreo No solo supervisa la fecha de caducidad en el repositorio del ACME-Worker. Comprueba de forma independiente el nombre de host proporcionado, el tiempo restante de validez del certificado que allí figura y si la recarga se ha realizado correctamente tras una actualización. También se debe generar una alerta si falla una renovación o si un punto final sigue emitiendo el certificado antiguo a pesar de que la emisión se haya realizado con éxito. Para los cambios previstos en los servidores de alojamiento, el artículo añade Planificar de forma segura las actualizaciones de cPanel y WHM la planificación operativa necesaria.

Límites de tarifas y renovaciones en la cartera

En una cartera de certificados, los límites de cuotas son una condición de diseño de la Automatización de SSL. Las renovaciones forzadas a diario o las tareas iniciadas simultáneamente generan órdenes innecesarias y pueden activar límites. Esto es especialmente cierto cuando un error de infraestructura afecta a muchos dominios a la vez: las repeticiones no solucionan ni la falta de archivos de desafío ni los datos DNS erróneos, pero sí aumentan el número de validaciones fallidas. Por lo tanto, los errores deben isolarse antes de la siguiente ejecución en producción.

Información sobre la renovación de ACME, en resumen ARI, sustituye los umbrales locales fijos por una ventana de renovación recomendada por el servidor ACME para un certificado existente. El cliente compatible con ARI consulta la información de renovación y elige un momento aleatorio dentro de esa ventana. Un programador puede iniciar el cliente periódicamente, pero no evalúa la ARI por sí mismo. El cliente debe utilizar la ventana recomendada y Retry-After tener en cuenta estos aspectos y, en caso de errores, respetar los intervalos adecuados de retroceso y repetición. Por lo tanto, una mayor frecuencia en la ejecución del programador no debe dar lugar a repeticiones incontroladas de tareas fallidas.

En el caso de Let’s Encrypt, las renovaciones coordinadas por ARI pueden quedar exentas de los límites de frecuencia, siempre que se cumplan los requisitos documentados. La nueva solicitud debe incluir, entre otros datos, al menos un identificador del certificado que se va a sustituir, y este no debe haber sido sustituido ya a través de ARI. Esto no supone una autorización general para cualquier nueva solicitud: los cambios en el alcance del certificado deben tratarse por separado, tanto desde el punto de vista técnico como operativo.

En particular, una lista SAN reducida o modificada no supone automáticamente una renovación del certificado anterior. Una solicitud que incluya solo una parte de los nombres anteriores puede generar un certificado independiente, mientras que el antiguo sigue siendo válido. Por lo tanto, el inventario debe incluir el identificador del certificado, la lista completa de identificadores, los puntos finales asignados y el procedimiento de renovación. Antes de realizar un cambio previsto en la lista SAN, hay que decidir qué servicios se van a adaptar y cuándo se eliminarán los certificados que ya no sean necesarios.

Cuando hay varios trabajadores, establecer una responsabilidad clara evita que se generen órdenes duplicadas para el mismo stock. Es recomendable contar con un programador central o un bloqueo coordinado, registros trazables y repeticiones escalonadas tras un error. La selección aleatoria dentro de una ventana ARI no sustituye a este control, sino que, sobre todo, reduce la simultaneidad de las renovaciones regulares.

Elegir el modelo operativo adecuado en función del riesgo

Para un único sitio web accesible al público, HTTP-01 suele ser el modelo de funcionamiento más sencillo. El servidor web debe atender de forma fiable el puerto 80 y entregar el archivo de desafío en la ruta esperada. Este modelo no es compatible con los comodines y se vuelve inestable cuando varios destinos independientes responden al mismo dominio. Por lo tanto, resulta especialmente adecuado cuando el enrutamiento web, el almacenamiento de certificados y la entrega de TLS se concentran en un punto claramente controlado.

El modelo DNS-01 es el más adecuado para comodines, subdominios dinámicos y puntos finales TLS distribuidos. El requisito previo no es simplemente tener acceso al DNS, sino poder modificar de forma segura y automatizada el registro TXT necesario. Un token lo más restringido posible o una zona de desafío delegada reduce las consecuencias de un sistema comprometido. El nivel de granularidad que se puede alcanzar depende de la API de DNS. Las delegaciones deben documentarse como una dependencia operativa, supervisarse y contar con un procedimiento de recuperación.

TLS-ALPN-01 es adecuado para operadores que controlan de forma específica la terminación TLS en el puerto 443, por ejemplo, en un proxy inverso o un equilibrador de carga. Este método no es un sustituto general de HTTP-01 ni admite comodines. Su viabilidad práctica depende además de la implementación concreta del cliente y del proxy. Por lo tanto, antes de utilizarlo hay que comprobar si el software es capaz de generar el desafío, enviarlo y eliminarlo correctamente una vez finalizado el proceso.

El Perfil de shortlived Solo es adecuado para sistemas con automatización integral de extremo a extremo. Let’s Encrypt describe para ello un periodo de validez de unas 160 horas, así como identificadores DNS e IP; en comparación con el perfil estándar de 90 días, esto aumenta considerablemente, en términos teóricos, la frecuencia de renovación necesaria. Por lo tanto, cada fase del proceso, desde el pedido hasta la distribución, la recarga y la verificación externa, debe funcionar de forma fiable. La elección de un perfil requiere, además, que el cliente ACME utilizado sea realmente compatible con la selección de perfiles.

Independientemente del modelo, se necesita un Gestión de certificados un inventario completo, claves gestionadas de forma segura y accesos al DNS con privilegios mínimos. La clave de la cuenta autentica al cliente para la cuenta ACME; la clave privada utilizada en la CSR forma parte de la identidad TLS. La RFC 8555 prohíbe utilizar la clave pública de la cuenta en un certificado: en particular, la clave de la CSR no debe coincidir con la clave de la cuenta que autentica la orden de finalización. El almacenamiento separado, la asignación de permisos y la rotación de estas clases de claves, así como los accesos revocables y una vía de retorno probada al certificado anterior, forman parte del concepto de derechos y de contingencia.

Una ejecución satisfactoria de ACME no debe ser el único criterio de éxito. El control de entrega debe determinar, fuera del worker, qué certificado presenta un punto final TLS auténtico. Para los pasos de distribución y recarga, son adecuadas las acciones que solo se activan tras una renovación satisfactoria; en Certbot se ha previsto un «deploy hook» para ello. Su script debe ser idempotente, registrar los errores y recargar únicamente aquellos servicios que realmente utilicen el material renovado.