Pourquoi un certificat auto-hébergé se renouvelle-t-il localement, mais échoue-t-il depuis Internet ?
Un certificat peut se renouveler localement tout en échouant publiquement lorsque l’autorité ACME ne peut pas atteindre ou vérifier le défi via le chemin exposé à Internet.
Sur un NAS auto-hébergé ou un serveur domestique, un test à blanc local peut confirmer que Certbot, acme.sh ou le proxy inverse peut créer les fichiers de défi et accéder à sa propre configuration. L’émission publique impose d’autres exigences : le DNS faisant autorité doit pointer vers la bonne adresse, le chemin IPv4 ou IPv6 sélectionné doit être accessible, le routeur et le pare-feu doivent transmettre la requête de validation, et le proxy inverse doit servir le jeton de défi exact avant que les redirections ou les routes de l’application n’interfèrent.
Distinguer la réussite du client local de la validation publique du domaine
Lisez le journal de renouvellement et identifiez précisément ce qui a réussi. Une vérification de configuration locale, un test d’analyse du certificat, l’écriture dans le webroot ou une requête de préproduction ne prouvent pas qu’une autorité de certification externe a atteint le serveur domestique.
Un cas courant avec Nginx Proxy Manager identifie l’accessibilité du port 80 public comme première exigence à vérifier lorsqu’un défi HTTP échoue malgré une interface de proxy locale fonctionnelle.
Notez le type de défi, le nom d’hôte, l’URL de validation, l’adresse résolue et l’erreur exacte de l’autorité de certification. Poursuivez uniquement à partir du premier échec externe — recherche DNS, connexion TCP, statut HTTP, discordance du jeton ou validation secondaire — au lieu de forcer à répétition le renouvellement sans nouvel élément.
Comparer les enregistrements A et AAAA faisant autorité avec le véritable chemin vers le serveur
Interrogez chaque nom d’hôte du certificat via le DNS faisant autorité et notez ses réponses A et AAAA. Comparez-les avec l’adresse IPv4 publique actuelle du routeur, l’adresse IPv6 accessible du serveur et le proxy qui sert réellement le défi.
Un cas de renouvellement avec Virtualmin n’a réussi qu’après la suppression d’un enregistrement AAAA publié qui envoyait la validation vers un chemin IPv6 défaillant, démontrant comment un chemin de validation AAAA défaillant peut prendre le dessus sur une configuration IPv4 par ailleurs saine.
Si une famille d’adresses n’est pas entièrement accessible, supprimez temporairement cet enregistrement ou réparez son pare-feu, son routage, son écouteur et son chemin proxy. Vérifiez également que tous les serveurs de noms faisant autorité renvoient les mêmes enregistrements à jour avant de relancer l’émission.
Tester l’URL exacte du défi HTTP depuis l’extérieur du domicile
Pour HTTP-01, placez un fichier de test inoffensif dans le chemin /.well-known/acme-challenge/ configuré et demandez-le depuis un réseau mobile ou un autre réseau externe, en utilisant le nom d’hôte du certificat via HTTP.
Un rapport sur l’auto-hébergement de Home Assistant montre comment un défi HTTP bloqué par le FAI empêche la validation HTTP, même lorsque le service fonctionne localement.
La requête externe doit atteindre le jeton correct sans authentification, page captive, écran de connexion du routeur, erreur 404 de l’application ni redirection vers une destination inaccessible. Si le port TCP 80 ne s’ouvre jamais, examinez le FAI, le CGNAT, la redirection du routeur, le pare-feu de l’hôte et l’écouteur du proxy avant de modifier le client ACME.
Vérifier que le proxy inverse et le webroot servent le même jeton
Comparez le chemin du jeton écrit par le client ACME avec le système de fichiers ou le répondeur temporaire utilisé par l’hôte virtuel public. Les conteneurs, les montages liés et les réseaux de proxy distincts peuvent amener le client à écrire dans un répertoire tandis que NGINX ou Caddy en sert un autre.
Examinez le journal d’accès du proxy pendant une requête de défi externe. Une requête qui arrive mais renvoie une erreur 404 indique une discordance de route ou de webroot ; une erreur 401 ou 403 indique une authentification ou un filtrage ; une erreur 502 indique une dépendance inutile envers un service en amont dans le chemin du défi.
Donnez la priorité à l’emplacement du défi par rapport au routage normal de l’application et conservez le nom d’hôte. Gardez les redirections simples et vérifiez-les depuis l’extérieur ; ne faites pas transiter le jeton par une application backend qui pourrait être hors ligne lors du renouvellement.
Vérifier le CGNAT, les pare-feu et l’accessibilité depuis plusieurs emplacements
Comparez l’adresse WAN du routeur avec l’adresse IPv4 publique et confirmez que le port de validation est accessible depuis plusieurs réseaux externes. Un test local de bouclage NAT peut réussir alors que le trafic Internet entrant non sollicité n’atteint jamais le routeur.
Les autorités de certification valident de plus en plus souvent depuis plusieurs emplacements réseau afin de réduire les attaques de routage. Les recherches sur les points d’observation de validation multiples expliquent pourquoi un chemin accessible depuis un pays, un FAI ou un service de test peut tout de même échouer lors d’une validation plus large.
Supprimez le géoblocage, les filtres par pays, les règles de refus temporaires et les limites de débit du chemin de défi restreint pendant la validation. Si la connexion domestique est derrière un CGNAT ou si le FAI bloque le port requis, utilisez DNS-01 ou une solution de validation sortante au lieu d’affaiblir des règles de pare-feu sans rapport.
Choisir le type de défi adapté à la limite du réseau
Conservez HTTP-01 lorsque le DNS public est correct et que le port 80 peut atteindre de manière fiable le répondeur du défi. Utilisez DNS-01 lorsque l’accessibilité entrante est indisponible, que des certificats génériques sont nécessaires ou que le service doit rester privé.
L’article de ZimaSpace sur la manière dont le CGNAT bloque la validation entrante aide à déterminer quand il est préférable de changer de méthode ACME plutôt que de réparer le proxy local.
La correction est terminée uniquement lorsqu’un renouvellement forcé réussit via l’autorité de certification de production, que le nouveau certificat est déployé sur le proxy actif, que les clients externes reçoivent le nouveau numéro de série et la nouvelle date d’expiration, et qu’un test de renouvellement sans surveillance fonctionne sans modification manuelle des ports ou du DNS.
Produits recommandés
Assistance et conseils
Plus à lire
Plex peut-il partager un GPU avec un autre conteneur Docker ?
Plex et un autre conteneur peuvent souvent accéder au même GPU, mais vous devez tester la prise en charge des pilotes, le mappage des...
Comment déterminer si une erreur Plex vient du client ou du serveur
Reproduisez le même élément sur un autre client, comparez le chemin de session, puis recueillez les preuves côté serveur uniquement après que la portée...
Comment configurer le cache de Plex et le stockage temporaire du transcodage
Protégez l’état persistant de Plex en plaçant les fichiers temporaires de transcodage sur un stockage local adapté, puis vérifiez le nettoyage, l’espace libre et...
