Diagnóstico de Let's Encrypt — por qué falla certbot

Porque el desafío HTTP-01 siempre empieza en el puerto 80. La autoridad de certificación se conecta ahí primero, con independencia de lo que haga su sitio después, y un cortafuegos que descarta el puerto 80 hace imposible el desafío. Redirigir el puerto 80 a HTTPS está bien: la CA sigue la redirección y no comprueba el certificado al hacerlo. Cerrar el puerto no lo está. Si de verdad no puede abrirlo, DNS-01 es la alternativa.

Sí. Antes de la emisión no existe archivo de desafío, así que un 404 es lo que debe devolver un servidor bien configurado. Lo que importa es que la petición llegara siquiera a su servidor web. Durante la validación certbot coloca el token real en esa ruta y la CA lo encuentra. Un fallo de conexión o un 403 significan que la petición nunca llegó, y ese es el problema de verdad.

Un registro DNS que indica qué autoridades de certificación pueden emitir para su dominio. Las autoridades están obligadas a comprobarlo y a rechazar si no figuran. La gente los adquiere del asistente de configuración de un proveedor anterior, de un panel de hosting o heredados de un dominio superior: un registro en example.com se aplica también a www.example.com, y por eso «yo nunca creé uno» suele ser falso.

De forma indirecta, y ese es el objetivo. Let's Encrypt limita cuántos certificados se pueden pedir por dominio y semana, y son los intentos fallidos repetidos los que agotan la cuota. Comprobar las condiciones previas antes de relanzar certbot es lo que evita quemarla en intentos que iban a fallar de todos modos.

No, y nunca lo hará. No realiza operaciones ACME, no guarda ninguna clave y no habla con ninguna autoridad de certificación: solo observa su dominio desde fuera. La emisión corresponde a su servidor, donde vive la clave privada y donde la renovación puede ser automática, cosa que una página web no puede ofrecer.