Diagnostic Let's Encrypt — pourquoi certbot échoue

Parce que le défi HTTP-01 commence toujours sur le port 80. L'autorité de certification s'y connecte d'abord, quoi que fasse votre site ensuite, et un pare-feu qui bloque le port 80 rend le défi impossible. Rediriger le port 80 vers HTTPS ne pose aucun problème : l'AC suit la redirection et ne vérifie pas le certificat au passage. Fermer le port, si. Si vous ne pouvez vraiment pas l'ouvrir, DNS-01 est l'alternative.

Oui. Avant l'émission il n'existe aucun fichier de défi : un 404 est donc ce que doit renvoyer un serveur correctement configuré. Ce qui compte, c'est que la requête ait atteint votre serveur web. Pendant la validation, certbot dépose le vrai jeton à ce chemin et l'AC le trouve. Un échec de connexion ou un 403 signifient que la requête n'est jamais arrivée : c'est là le vrai problème.

Un enregistrement DNS désignant les autorités de certification autorisées à émettre pour votre domaine. Les autorités sont tenues de le consulter et de refuser si elles n'y figurent pas. On en hérite de l'assistant de configuration d'un prestataire précédent, d'un panneau d'hébergement, ou d'un domaine parent : un enregistrement sur example.com s'applique aussi à www.example.com, d'où le fréquent « je n'en ai jamais créé » qui se révèle faux.

Indirectement, et c'est justement l'intérêt. Let's Encrypt limite le nombre de certificats demandés par domaine et par semaine, et ce sont les tentatives infructueuses répétées qui épuisent le quota. Vérifier les conditions avant de relancer certbot évite de le brûler sur des tentatives vouées à l'échec.

Non, et il ne le fera jamais. Il n'effectue aucune opération ACME, ne détient aucune clé et ne dialogue avec aucune autorité de certification : il se contente d'observer votre domaine de l'extérieur. L'émission appartient à votre serveur, là où vit la clé privée et où le renouvellement peut être automatique — ce qu'une page web ne peut pas offrir.