Renovación SSL fallida: diagnosticar antes de reintentar

Un certificado gratuito se renueva solo, sin que nadie haga clic. Cuando caduca de todos modos, la conclusión espontánea es que el servicio automático ha fallado. Rara vez es cierto. La renovación no es una acción del proveedor: es un diálogo entre la autoridad de certificación y su dominio, repetido en cada vencimiento, y solo tiene éxito si el dominio responde como la primera vez.

Pero un sitio evoluciona. Alguien cambió los servidores DNS, añadió una regla de redirección en el archivo .htaccess, activó un cortafuegos de aplicaciones web, puso el dominio detrás de un CDN o publicó un registro CAA. Cada uno de estos gestos es legítimo, y cada uno puede impedir la validación sin que el sitio deje de mostrarse. El error aparece semanas después, en el vencimiento, lejos del cambio que lo provocó. Relanzar la emisión sin corregir nada solo produce el mismo fallo. Hay que leer la señal, encontrar la condición que se movió, restablecerla y relanzar una sola vez.

Para emitir o renovar un certificado, la autoridad debe asegurarse de que quien lo pide controla realmente el dominio. Procede en cuatro tiempos, y el fallo está siempre en uno de ellos.

Primero resuelve el nombre: el DNS debe responder y devolver la dirección del servidor correcto, tanto en IPv4 como en IPv6. Después, en la validación por archivo, solicita http://your-domain.com/.well-known/acme-challenge/ en el puerto 80 y espera el contenido exacto que colocó el cliente ACME. En tercer lugar consulta los registros CAA del dominio para comprobar que ninguno le prohíbe emitir. Por último, sigue las redirecciones eventuales, pero rechaza una respuesta de error o una página de bloqueo.

Esta secuencia explica el árbol de diagnóstico: ¿el dominio apunta al servidor correcto?, ¿es accesible el desafío?, ¿lo intercepta una redirección o un cortafuegos?, ¿un CAA excluye a la autoridad?, ¿está el proxy en un modo compatible? Los pasos siguientes prueban estos cinco puntos en ese orden.

Es la causa más frecuente y la más discreta. Tras una migración, un cambio de proveedor o una limpieza de zona, el dominio sigue mostrándose gracias a la caché o a un registro A correcto, mientras que un registro AAAA sigue apuntando al servidor antiguo. La autoridad prefiere IPv6 cuando existe: consulta la máquina antigua, que ya no conoce el archivo del desafío, y la validación falla aunque desde su equipo todo parezca en orden.

La comprobación es sencilla: compare dig +short A your-domain.com y dig +short AAAA your-domain.com con la dirección real del servidor. Si no usa IPv6, elimine el registro AAAA en lugar de dejarlo apuntando a otro sitio. Verifique también que el dominio usa los servidores de nombres donde acaba de corregir la zona; el procedimiento para modificar un registro se detalla en la guía para añadir o modificar un registro DNS. Después, espere a que termine el plazo de caché anunciado por el valor antiguo antes de relanzar.

El desafío es una petición HTTP corriente que la autoridad envía desde sus propios servidores. Todo lo que responda en su lugar, o le responda algo distinto del archivo esperado, hace fallar la validación. Tres configuraciones causan el problema con regularidad.

La primera es la redirección que cambia de dominio: una regla que envía todo el tráfico de your-domain.com a otra dirección, incluida la ruta del desafío, manda a la autoridad a buscar el archivo a un sitio que no lo tiene. La segunda es la regla de seguridad que rechaza los archivos cuyo nombre empieza por un punto: protege .env o .git, pero también bloquea .well-known. La tercera es el cortafuegos de aplicaciones o el filtrado por país, que trata a la autoridad como un visitante desconocido y responde 403.

La solución no es desactivar la protección, sino excluir con precisión la ruta /.well-known/acme-challenge/ de las reglas de redirección y bloqueo. Una redirección de HTTP a HTTPS sigue siendo aceptable, siempre que conserve la ruta solicitada y termine en el mismo dominio.

Un registro CAA es una lista blanca publicada en el DNS: enumera las autoridades autorizadas a emitir para el dominio. Es una buena herramienta de seguridad, pero caduca en silencio. Alguien publica 0 issue "an-authority.example" durante una auditoría, luego el alojamiento pasa a otra autoridad, o AutoSSL cambia de proveedor, y la emisión se rechaza con un mensaje que menciona CAA.

Para corregirlo, lea el resultado de dig CAA your-domain.com +short, identifique la autoridad que usa su servicio (en cPanel, la columna Emisor de la página Certificados SSL) y añada una línea issue con su nombre. Si no necesita esta restricción, elimine el registro. Recuerde que un CAA se lee subiendo por el árbol: el del dominio principal se aplica a los subdominios. Y para un certificado que cubre un subdominio comodín, puede hacer falta una línea issuewild aparte.

Poner un dominio detrás de un CDN en modo proxy cambia lo que ve la autoridad. Ya no habla con su servidor, sino con el del CDN, que puede responder en su lugar con un certificado de borde, una página de verificación o una regla de seguridad propia. Según el modo elegido, la renovación del certificado de origen funciona o no.

Importan dos ajustes. Primero, el modo de cifrado entre el CDN y el origen: en modo flexible, el CDN habla en claro con el origen, lo que provoca un bucle de redirección si su servidor fuerza HTTPS; en modo estricto, exige un certificado de origen válido, de modo que la caducidad se hace visible de inmediato como un error de origen. Segundo, las protecciones activas en la ruta del desafío: hay que levantarlas para /.well-known/acme-challenge/ o pasar a una validación por registro DNS, que no depende del tráfico web. Durante el diagnóstico también puede desactivar temporalmente el proxy en el único registro afectado, relanzar la emisión y volver a activarlo.

Una renovación que falla casi siempre indica que ha cambiado una condición de validación: el nombre ya no apunta al lugar correcto, la ruta del desafío está bloqueada o desviada, se excluye a una autoridad, un proxy se ha colado entre ella y el servidor. El orden de lectura es constante: resolución DNS, acceso al puerto 80, respuesta en la ruta del desafío, registro CAA, modo del proxy. Una vez restablecida la causa, basta un solo reintento. El alojamiento web de ServOrbit.com incluye SSL gratuito renovado automáticamente; cuando la validación falla, la causa se lee en el registro de AutoSSL y se corrige con los comandos anteriores.