La documentation IPv6 de Let’s Encrypt rappelle qu’un ancien enregistrement AAAA peut empêcher la validation d’un domaine. Sur cPanel/WHM, commencez donc par le journal AutoSSL du nom exact en échec, même si la page d’accueil fonctionne depuis votre connexion.
1. Lire l’échec avant de relancer
Dans WHM, ouvrez Manage AutoSSL, puis Logs. Sélectionnez l’exécution concernée et notez le compte, le domaine, la méthode DCV et le message complet. Les fichiers sont également disponibles dans /var/cpanel/logs/autossl pour l’administrateur.
Vérifiez que le fournisseur AutoSSL est actif et que le compte bénéficie bien de la fonctionnalité. Un domaine non résolu, une validation refusée et un certificat installé mais mal servi nécessitent trois enquêtes différentes.
Préparez une ligne de suivi par nom : domaine, adresse attendue, erreur et correction proposée. Ne supprimez pas un certificat encore valide pour « repartir de zéro » ; cela ne corrige pas la cause de validation.
2. Vérifier la destination réellement utilisée
Remplacez example.com par le nom signalé :
dig +short A example.comdig +short AAAA example.comdig +short CAA example.comcurl -4I http://example.com/curl -6I http://example.com/Ces appels HTTP vérifient une destination générale, pas le challenge DCV lui-même. Un test IPv6 exige aussi une connexion cliente IPv6 fonctionnelle. Comparez les réponses avec les adresses prévues et, si nécessaire, interrogez le DNS faisant autorité.
Let’s Encrypt essaie d’abord IPv6 lorsqu’un nom possède les deux familles d’adresses. Une réponse incorrecte d’un ancien serveur IPv6 ne déclenche pas automatiquement un nouvel essai IPv4. Corrigez le AAAA ou retirez-le si le service ne doit plus utiliser IPv6.
Pour une erreur HTTP DCV, examinez le chemin exact indiqué dans le journal : redirection, authentification, WAF ou mauvais dossier peuvent détourner la validation. Limitez toute exception au mécanisme nécessaire. Pour une erreur CAA, vérifiez l’autorisation effective du fournisseur, y compris la politique héritée ; n’effacez pas toute la politique DNS.
3. Vérifier la réparation et sa durée
Après correction et prise en compte du DNS, lancez un contrôle AutoSSL ciblé depuis l’interface. Lisez son nouveau résultat avant d’en demander un autre : répéter les tentatives sans changement ne constitue pas un diagnostic.
Contrôlez ensuite le certificat présenté au navigateur pour chaque nom, ses dates et sa chaîne. Si un proxy termine TLS, distinguez son certificat de celui du serveur d’origine.
Activez les notifications d’échec adaptées dans Manage AutoSSL et vérifiez leurs destinataires. Conservez l’erreur initiale et la preuve du contrôle réussi, puis surveillez la prochaine exécution automatique. Une émission manuelle réussie confirme la correction immédiate ; le suivi du cycle automatique confirme que le renouvellement reste opérationnel.
Sources : cPanel — Manage AutoSSL, Let’s Encrypt — IPv6.