Resumen

  • RFC 9773 permite que una autoridad de certificación recomiende cuándo intentar la renovación y que un pedido nuevo identifique el certificado anterior. El cliente sigue siendo responsable de elegir un instante aleatorio, conservar el retroceso y el plan alternativo, completar ACME y desplegar el resultado.
  • Una suggestedWindow, un replaces aceptado, un pedido valid, un certificado descargado, una entrada de CT, un archivo instalado y una negociación TLS observada son pruebas distintas. Ninguna debe hacerse pasar por la siguiente.

El indicador verde se comió seis estados

En la pantalla hay una sola palabra: renovado. Detrás de ella pueden existir seis relojes que no marcan lo mismo.

La autoridad de certificación indica el período en el que desea recibir el trabajo. El cliente elige un instante dentro de ese período. Retry-After marca cuándo volver a consultar la información. El retroceso de errores limita cuándo reintentar una operación fallida. El sistema de despliegue decide cuándo distribuir y recargar. Por último, el servicio expuesto revela en una nueva conexión qué certificado está usando de verdad.

Si todos esos tiempos acaban en un campo llamado next_run, la explotación pierde la capacidad de explicar un retraso. No sabrá si espera una nueva consulta, una fecha elegida, la recuperación de un fallo, la emisión por parte de la autoridad, una recarga local o la convergencia de una región.

Pensemos en una flota que recibe una ventana de veinticuatro horas. La autoridad ha hecho una contribución razonable: apartar las renovaciones de un pico futuro y dar margen a los clientes para distribuirse. Sin embargo, en el siguiente despertar común, la gráfica sube como una pared.

Quizá los clientes redondearon sus instantes al mismo límite de cron. Quizá no podían dormir hasta una hora exacta y ejecutaron al comprobar que la selección era anterior al siguiente despertar. Algunas instancias pudieron perder el estado de fallo al reiniciarse. Un orquestador pudo reunir decisiones individuales en una única tarea de flota.

No se trata de atribuir un incidente real a una entidad concreta. Es un escenario analítico que muestra la frontera central de ARI: una ventana compartida puede orientar el conjunto, pero no controla cómo cada sistema local interpreta y ejecuta el tiempo.

El directorio anuncia dónde pedir consejo

Un servidor ACME compatible con ARI incorpora una URL renewalInfo a su objeto de directorio. Para consultar un certificado, el cliente construye un identificador reproducible: codifica en base64url el keyIdentifier de Authority Key Identifier, añade un punto y codifica en base64url los bytes DER del número de serie, sin el relleno final. Después hace un GET no autenticado.

Ese identificador permite que implementaciones independientes hablen del mismo certificado. No convierte la respuesta en una orden de despliegue.

El objeto RenewalInfo contiene obligatoriamente una suggestedWindow con start y end. Los límites señalan el período durante el cual la autoridad recomienda intentar la renovación. Una explanationURL opcional puede explicar una estrategia dinámica de carga o la necesidad de adelantarse a una revocación masiva.

La palabra recomendación protege tres separaciones.

La ventana no es la validez X.509 y no modifica notBefore ni notAfter. Tampoco es una respuesta CRL u OCSP y no declara por sí misma que el certificado anterior esté revocado. Finalmente, que el recurso exista no demuestra que el cliente lo haya consultado, que haya aceptado el dato o que haya iniciado un pedido.

Una autoridad puede situar toda la ventana en el pasado para recomendar una acción inmediata. Un reloj atrasado podría verla aún en el futuro. Un cliente sin ARI no la verá. La visión global mejora el consejo, pero no sustituye la adopción local.

El cliente conserva la decisión aleatoria

RFC 9773 recomienda escoger de forma uniforme un instante dentro de la ventana. Si ya pasó, el cliente intenta renovar de inmediato. Si puede programarse con exactitud, espera. Si el instante elegido cae antes de su próximo despertar normal, actúa ahora. En otro caso espera hasta la siguiente consulta de RenewalInfo y vuelve a evaluar.

La autoridad no entrega una cita exacta por certificado. Para hacerlo con seguridad tendría que conocer la resolución del planificador, las ventanas de mantenimiento y las reglas de recuperación de cada suscriptor. El intervalo permite coordinar la carga general sin apropiarse de la ejecución.

Pero una selección aleatoria no garantiza por sí sola una curva plana. El instante debe persistir para que un reinicio no vuelva a sortear. Las instancias clonadas no deberían compartir un estado pseudoaleatorio que produzca resultados iguales. Un planificador con resolución horaria puede destruir la dispersión de una ventana amplia. Un trabajo superior de flota no debe reemplazar miles de decisiones por un único disparador.

Los clientes periódicos también tienen que conservar los fallos. Elevar la frecuencia de consulta sin recordar cuántos intentos fallaron y cuándo ocurrió el último elimina el retroceso. Un sistema sin memoria transforma una mejor observación en más presión sobre la autoridad.

Una ventana con end igual o anterior a start no es válida. El cliente la trata como una respuesta inutilizable y sigue una política local de reintento o un calendario alternativo. El origen esperado no da autoridad a un dato contradictorio.

Retry-After no programa el pedido

En ARI, Retry-After expresa el intervalo deseado hasta la próxima lectura de RenewalInfo. Es a la vez el mínimo y el máximo solicitados, con límites locales razonables y con prioridad para el retroceso de errores.

No dice cuándo crear el pedido de certificado.

Si el cliente recibe Retry-After: 21600, conoce una cadencia de seis horas para refrescar información. El instante escogido dentro de la ventana sigue siendo otro dato. Confundir ambos tiempos impide distinguir una espera deliberada de una consulta desactualizada.

Los errores temporales —tiempo de conexión, tiempo de solicitud y respuestas 5xx— requieren retroceso exponencial con un número acotado de intentos. Cuando se agotan, o ante un problema duradero como Retry-After ausente o inválido, objeto inválido, fallo DNS, conexión rechazada o error no-5xx, el cliente vuelve después de seis horas o del intervalo local equivalente.

Let’s Encrypt recomienda como práctica consultar ARI al menos dos veces al día por certificado y mantener un criterio alternativo según la vida restante. Es una orientación operativa de una autoridad concreta, no una constante universal de RFC 9773. El registro debe identificar qué regla procede de la norma, cuál de la autoridad y cuál del operador.

replaces da linaje al pedido

ARI añade el campo opcional replaces al objeto de pedido. Usa el mismo identificador de certificado y declara qué predecesor pretende sustituir el nuevo pedido.

El linaje tiene valor. La autoridad puede reconocer renovaciones, aplicar prioridad o tratamiento de límites según su política y seguir el reemplazo de certificados afectados por un incidente. El servidor comprueba la relación entre cuenta, identificadores y certificado anterior. Si otro pedido no inválido ya lo marcó como sustituido, responde HTTP 409 con alreadyReplaced.

Sin embargo, la aceptación solo prueba una relación en la emisión. No demuestra que el cliente descargara el sucesor, que coincida con la clave privada, que llegara al balanceador, que el proceso se recargara o que el predecesor dejara de aparecer.

Incluso la palabra reemplazado en el registro de la autoridad debe leerse según el significado ACME: existe una sucesión de pedidos. Ampliarla hasta el estado de una infraestructura que la autoridad no observa sería convertir información útil en una falsa garantía.

valid no instala bytes

RFC 8555 sigue gobernando la emisión. El cliente crea un pedido, satisface las autorizaciones de identificadores cuando corresponda, envía una CSR a la URL de finalización, espera la emisión y descarga desde la URL de certificado incorporada al pedido.

ready significa que el servidor considera satisfechos sus requisitos y espera finalización. processing indica que la emisión está en curso. valid significa que la autoridad emitió el certificado y proporcionó la URL. Una descarga correcta prueba que se recibieron los bytes.

Nada de ello los activa en un servicio.

Después vienen la custodia de claves, la composición de la cadena, la comprobación de correspondencia, los permisos, la distribución, la validación de configuración, la recarga, el drenaje de conexiones, la réplica regional y la vuelta atrás. Puede haber un archivo nuevo junto a un proceso viejo que nunca lo reabrió. Una región puede estar actualizada y otra presentar aún el certificado anterior.

Un estado explicable necesita transiciones separadas:

  1. RenewalInfo obtenido y validado;
  2. instante elegido y persistido;
  3. pedido creado con linaje del predecesor;
  4. autorización y finalización completadas;
  5. certificado descargado, huella calculada y clave comprobada;
  6. artefacto entregado a objetivos nombrados;
  7. configuración validada y proceso recargado;
  8. conexión local nueva que presenta la huella esperada;
  9. observación externa en los caminos previstos;
  10. retirada del material anterior tras un período de recuperación limitado.

Un booleano renovado no simplifica esa cadena: oculta dónde quedó detenido el reemplazo.

CT registra emisión, no presencia en el servicio

RFC 9162 describe registros públicos de certificados TLS emitidos u observados. Certificate Transparency permite auditar a las autoridades, descubrir emisiones inesperadas y comprobar el carácter acumulativo del registro.

Una entrada CT es evidencia fuerte de emisión o presentación al registro. No es evidencia de despliegue.

Un precertificado puede entrar durante la emisión. Un tercero puede presentar la cadena. La entrada puede existir antes de que el suscriptor descargue el resultado. El registro no visita todos los extremos ni sabe qué balanceador tiene la clave privada correspondiente.

La inferencia correcta es que el certificado o precertificado entró en el mecanismo de transparencia bajo sus reglas. Para afirmar que el servicio público lo usa hace falta observar el servicio.

Una negociación nueva se acerca más a la realidad

En TLS 1.3 con autenticación por certificado, el servidor envía la cadena en Certificate, prueba la posesión de la clave mediante CertificateVerify y completa la transcripción con Finished.

Una conexión nueva, sin depender de una sesión anterior, permite observar qué huella presenta un extremo en ese instante. Debe compararse con el certificado descargado y repetirse por familia de direcciones, región, nombre SNI, nivel de terminación y camino relevante.

La prueba sigue acotada. Un camino IPv4 actualizado no prueba IPv6. Un sitio anycast no prueba todos. Una sonda interna puede terminar antes que el tráfico público. Una sesión reanudada puede no ofrecer el intercambio completo que se pretende examinar.

«A la hora T, el extremo E presentó la huella F por el camino P en una negociación nueva» es una afirmación auditable. «Desplegado globalmente» exige un plan de observación que cubra de verdad ese ámbito.

Un libro de evidencias causales

Por certificado, conviene conservar separados y enlazados:

  • identificador ARI, directorio ACME y última consulta correcta;
  • inicio y final de ventana, explicación, huella de respuesta y Retry-After;
  • instante elegido, método, desviación de reloj, resolución y persistencia;
  • umbral alternativo, fallos, último fallo y próxima hora permitida;
  • predecesor, cuenta, URL de pedido y resultado de replaces;
  • horas de autorización, finalización, emisión y descarga;
  • huella, cadena, coincidencia de clave y ubicación custodiada;
  • objetivos, controles de configuración, recargas y estado de vuelta atrás;
  • negociaciones nuevas por región, familia de direcciones y terminación;
  • retirada del predecesor y evidencia que permitió hacerla.

Las claves privadas, credenciales completas y topología sin filtrar no deben llegar a una superficie analítica general. Huellas, identificadores controlados y recibos con responsable bastan para preservar causalidad sin ampliar el acceso a secretos.

La autoridad informa consejo y emisión. El cliente informa selección y pedido. El sistema de despliegue informa custodia y recarga. El extremo presenta un certificado. El observador informa un camino. Ninguna capa necesita apropiarse de la certeza de la siguiente.

El código en funcionamiento completa la frase

Publicar una regla de coordinación no crea realidad operativa. Esta aparece cuando los participantes implementan, validan, despliegan y usan la regla.

La capa común de ARI es pequeña: anunciar el recurso, identificar el certificado, expresar una ventana, señalar una cadencia de consulta y nombrar un predecesor. No centraliza la agenda de despliegue del suscriptor ni declara cambiado un servicio.

La decisión local vive en el instante, el retroceso y el plan alternativo. La adopción voluntaria aparece cuando un cliente implementa ARI y decide cómo integrarlo. La primacía del sistema activo aparece al final: el nuevo certificado se vuelve realidad cuando los extremos lo presentan y lo usan.

La autoridad controla la ventana, no todos los relojes. El cliente controla el intento, no la emisión. El despliegue controla la instalación, no todos los caminos. Una sonda controla su observación, no la flota entera.

La separación no debilita la automatización. La convierte en una secuencia que puede medirse, detenerse y revertirse.

Fuentes