¿Por qué un certificado autohospedado se renueva localmente, pero falla desde Internet?
Un certificado puede renovarse localmente y, aun así, fallar públicamente cuando la autoridad ACME no puede acceder al desafío ni verificarlo a través de la ruta expuesta a Internet.
En un NAS autohospedado o un servidor doméstico, una prueba local puede confirmar que Certbot, acme.sh o el proxy inverso pueden crear archivos de desafío y acceder a su propia configuración. La emisión pública añade otros requisitos: el DNS autoritativo debe apuntar a la dirección correcta, la ruta IPv4 o IPv6 seleccionada debe ser accesible, el router y el firewall deben entregar la solicitud de validación, y el proxy inverso debe servir el token de desafío exacto antes de que interfieran las redirecciones o las rutas de la aplicación.
Separa el éxito del cliente local de la validación pública del dominio
Lee el registro de renovación e identifica qué fue lo que realmente se completó correctamente. Una comprobación de configuración local, una prueba de análisis del certificado, la escritura en el webroot o una solicitud de prueba no demuestran que una autoridad de certificación externa haya llegado al servidor doméstico.
Un caso habitual de Nginx Proxy Manager identifica la accesibilidad pública del puerto 80 como el primer requisito que se debe verificar cuando falla un desafío HTTP a pesar de que la interfaz local del proxy funciona correctamente.
Registra el tipo de desafío, el nombre de host, la URL de validación, la dirección resuelta y el error exacto de la CA. Continúa solo desde el primer fallo externo —búsqueda DNS, conexión TCP, estado HTTP, discrepancia del token o validación secundaria— en lugar de forzar repetidamente la renovación sin obtener nuevas pruebas.
Compara los registros A y AAAA autoritativos con la ruta real del servidor
Consulta cada nombre de host del certificado mediante el DNS autoritativo y registra sus respuestas A y AAAA. Compáralas con la IPv4 pública actual del router, la dirección IPv6 accesible del servidor y el proxy que realmente sirve el desafío.
Un caso de renovación en Virtualmin solo se resolvió después de eliminar un registro AAAA publicado que enviaba la validación a una ruta IPv6 defectuosa, lo que demuestra cómo una ruta de validación AAAA defectuosa puede anular una configuración IPv4 que, por lo demás, funciona correctamente.
Si una familia de direcciones no es completamente accesible, elimina temporalmente ese registro o corrige su firewall, enrutamiento, servicio de escucha y ruta del proxy. Comprueba también que todos los servidores de nombres autoritativos devuelvan los mismos registros actuales antes de volver a intentar la emisión.
Prueba la URL exacta del desafío HTTP desde fuera de casa
Para HTTP-01, coloca un archivo de prueba inofensivo en la ruta /.well-known/acme-challenge/ configurada y solicítalo desde datos móviles u otra red externa utilizando el nombre de host del certificado mediante HTTP.
Un informe sobre autohospedaje de Home Assistant muestra cómo un desafío HTTP bloqueado por el ISP impide la validación HTTP aunque el servicio funcione localmente.
La solicitud externa debe llegar al token correcto sin autenticación, una página cautiva, una pantalla de inicio de sesión del router, un error 404 de la aplicación ni una redirección a un destino inaccesible. Si el puerto TCP 80 nunca se abre, revisa el ISP, la CGNAT, la redirección del router, el firewall del host y el listener del proxy antes de cambiar el cliente ACME.
Verifica que el proxy inverso y el webroot sirvan el mismo token
Compara la ruta del token escrita por el cliente ACME con el sistema de archivos o el respondedor temporal utilizado por el host virtual público. Los contenedores, los montajes enlazados y las redes de proxy independientes pueden hacer que el cliente escriba en un directorio mientras NGINX o Caddy sirve otro.
Inspecciona el registro de acceso del proxy durante una solicitud de desafío externa. Una solicitud que llega pero devuelve 404 apunta a una discrepancia entre la ruta y el webroot; los códigos 401 o 403 apuntan a autenticación o filtrado; un 502 apunta a una dependencia innecesaria del backend en la ruta del desafío.
Da prioridad a la ubicación del desafío sobre el enrutamiento normal de la aplicación y conserva el nombre de host. Mantén las redirecciones simples y verifícalas externamente; no envíes el token a través de una aplicación backend que pueda estar fuera de servicio durante la renovación.
Comprueba la CGNAT, los firewalls y la accesibilidad desde varias ubicaciones
Compara la dirección WAN del router con la dirección IPv4 pública y confirma que el puerto de validación sea accesible desde más de una red externa. Una prueba local de NAT loopback puede tener éxito aunque el tráfico no solicitado de Internet nunca llegue al router.
Las autoridades de certificación validan cada vez más desde varias ubicaciones de red para reducir los ataques de enrutamiento. La investigación sobre múltiples puntos de observación de validación explica por qué una ruta accesible desde un país, ISP o servicio de prueba puede seguir fallando en una validación más amplia.
Elimina el bloqueo geográfico, los filtros por país, las reglas de denegación temporales y los límites de frecuencia de la ruta específica del desafío durante la validación. Si la conexión doméstica está detrás de CGNAT o el ISP bloquea el puerto necesario, utiliza DNS-01 o un diseño de validación saliente en lugar de debilitar reglas del firewall no relacionadas.
Elige el tipo de desafío que corresponda al límite de la red
Mantén HTTP-01 cuando el DNS público sea correcto y el puerto 80 pueda llegar de forma fiable al respondedor del desafío. Utiliza DNS-01 cuando la accesibilidad entrante no esté disponible, se necesiten certificados comodín o el servicio deba permanecer privado.
El artículo de ZimaSpace sobre cómo la CGNAT bloquea la validación entrante ayuda a identificar cuándo es más apropiado cambiar el método ACME que reparar el proxy local.
La solución solo está completa cuando una renovación forzada se realiza correctamente mediante la CA de producción, el nuevo certificado se implementa en el proxy activo, los clientes externos reciben el nuevo número de serie y la nueva fecha de caducidad, y una prueba de renovación desatendida funciona sin cambios manuales en los puertos ni en el DNS.
Productos recomendados
Soporte y Consejos
Más para leer
¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...
Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...
Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...
