Renovación automática y vidas cortas

En abril de 2025, el CA/Browser Forum, el foro donde las autoridades públicas y los fabricantes de navegadores fijan las reglas de los certificados TLS públicos, aprobó un calendario que reduce la vida máxima por etapas: desde el 15 de marzo de 2026, desde el 15 de marzo de 2027 y desde el 15 de marzo de 2029, cada vez más corta. El laboratorio trae las cifras de cada etapa.

La razón es de diseño. Una vida corta acota cuánto tiempo sirve una clave robada o un certificado mal emitido, y reduce la dependencia de la revocación, que, como viste en la sala anterior, llega tarde o no llega. El costo es operativo: nadie renueva a mano decenas de certificados cada pocas semanas sin equivocarse. La respuesta es la automatización, y el protocolo estándar para eso es ACME (RFC 8555, de 2019), en el que un cliente pide el certificado, demuestra que controla el dominio con un desafío y lo instala.

Las reglas del foro obligan a las autoridades públicas, no a las internas. Pero la lección vale para las dos: una PKI interna con vidas cortas y renovación automática falla menos que una de vidas largas y renovación manual.

El arquitecto traduce el calendario a carga de trabajo. Cada certificado necesita, como mínimo, tantas emisiones al año como veces cabe su vida máxima en un año, redondeando hacia arriba; en la práctica algunas más, porque se renueva antes de que venza. Multiplicado por los certificados que se renuevan a mano, sale la cifra que convence a la dirección de pagar la automatización.

Abre el laboratorio, lee calendario-de-vidas.txt y cuenta en certificados-publicos.txt los que se renuevan a mano.

Un cliente automático falla como cualquier otro sistema: el desafío deja de superarse porque alguien movió la zona de DNS, cambió un cortafuegos o retiró una ruta. El diseño no evita todas esas fallas; lo que sí decide es a quién avisa el cliente cuando falla y con cuánto margen. Renovar cuando queda un tercio de la vida da tiempo para reaccionar, pero solo si el aviso llega a alguien.

Lee cliente-acme.log de principio a fin, incluida la nota del final.

La segunda falla es más traicionera: el cliente obtiene el certificado nuevo, lo copia y da la renovación por buena, pero un nodo no recarga el servicio y sigue presentando el viejo. El monitor que mira el certificado en el almacén ve la fecha nueva; el cliente que se conecta a ese nodo ve la vieja. El día que vence, el sitio cae a medias, y las caídas a medias son las más difíciles de diagnosticar.

Compara la serie que emitió la renovación en cliente-acme.log con lo que presenta cada nodo en servido-en-cada-nodo.txt.

Las dos fallas de esta sala tienen la misma forma: el proceso se da por bueno en un punto intermedio. El diseño mueve la meta hasta el final.