Un certificat manquant n’implique pas forcément une panne de l’autorité de certification. AutoSSL doit couvrir le bon domaine, être autorisé pour le compte et réussir la validation de contrôle du domaine, ou DCV ; les journaux permettent de distinguer ces étapes.
Intention de recherche : réparer un échec AutoSSL et vérifier que le prochain renouvellement restera possible. La documentation AutoSSL et celle de Let’s Encrypt servent de point de départ ; la méthode ci-dessous sépare décision de couverture, DNS et chemin de validation.
1. Identifier le nom réellement en échec
Problème et causes possibles
Un site peut avoir un certificat valide pour l’apex mais pas pour www, mail ou un sous-domaine. Relevez chaque nom absent et le message exact, pas seulement « DCV failed ». Causes possibles : exclusion volontaire, compte désactivé pour AutoSSL, DNS obsolète, chemin HTTP filtré, CAA incompatible ou validation DNS non automatisable.
Dans WHM, SSL/TLS, Manage AutoSSL, examinez fournisseur, Manage Users et Logs. Dans cPanel, SSL/TLS Status, contrôlez les exclusions par domaine avant d’utiliser Include during AutoSSL. Un nom inutilisé qui pointe volontairement ailleurs ne doit pas être réinclus sans décision.
Les journaux se trouvent dans /var/cpanel/logs/autossl. Lisez le log de l’exécution concernée plutôt que de relancer tous les comptes :
ls -lt /var/cpanel/logs/autossldig +short NS example.comdig example.com Adig example.com AAAAdig example.com CAAdig www.example.com CAARemplacez example.com. Les réponses d’un résolveur local ne suffisent pas : interrogez aussi les serveurs autoritatifs identifiés, et comparez depuis un réseau externe.
Sauvegarde avant modification
Exportez la zone depuis son fournisseur autoritatif et relevez TTL, exclusions, fournisseur AutoSSL et règles de redirection actuelles. Avant de modifier le .htaccess du bon document root :
umask 077save=$(mktemp -d /root/autossl-before.XXXXXX)cp -a /home/cpuser/public_html/.htaccess "$save/"Adaptez le chemin ; s’il n’existe pas, notez cette absence au lieu d’exécuter la copie. Gardez les clés privées hors des tickets et des sorties partagées.
2. Corriger la couche qui empêche la validation
- DNS : vérifiez chaque A et AAAA et la cible des CNAME. Une ancienne IPv6 peut envoyer une validation vers une autre machine. Corrigez l’enregistrement erroné à la source ; ne supprimez pas IPv6 si un service en dépend. Une modification locale de zone n’aide pas quand les DNS publics sont hébergés ailleurs.
- CAA : assurez-vous que la politique effective autorise le fournisseur sélectionné, y compris pour un wildcard. Examinez les CAA hérités et les alias selon la réponse DNS. Faites corriger la règle concernée par son propriétaire plutôt que supprimer toute la politique.
- HTTP : pour HTTP-01 de Let’s Encrypt, le fichier de défi est recherché sous
/.well-known/acme-challenge/via le port 80. Utilisez le chemin exact donné par le log pour votre fournisseur. Vérifiez redirections, authentification, WAF, CDN et routage vers le bon document root.
url=http://example.com/.well-known/acme-challenge/probecurl -4 -sS -D - -o /dev/null "$url"curl -6 -sS -D - -o /dev/null "$url"Ce fichier probe n’existe pas nécessairement : un 404 ne prouve ni succès ni échec DCV. Pour tester le routage, placez temporairement un fichier inoffensif à cet emplacement dans le document root confirmé, contrôlez son contenu de l’extérieur puis retirez-le. Il ne remplace pas le vrai jeton AutoSSL.
4. DNS : un wildcard nécessite DNS-01 avec Let’s Encrypt. Vérifiez que le mécanisme disponible peut mettre à jour le TXT autoritatif sous _acme-challenge ; éditer uniquement une zone cPanel non autoritative ne suffit pas.
5. Après correction et visibilité publique, lancez Check sur le compte concerné dans Manage AutoSSL. Lisez le nouveau résultat et les éventuels noms encore exclus.
Retour arrière
Si une correction DNS ou redirection casse un service, restaurez uniquement les valeurs relevées pour cette modification. Ne remettez pas un certificat expiré et ne supprimez pas un certificat valide pour provoquer une nouvelle émission.
3. Vérification finale
Contrôlez le certificat réellement présenté :
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null |openssl x509 -noout -dates -ext subjectAltNameRépétez pour les noms et points de terminaison utiles. Derrière un CDN, cette commande examine le certificat de bord, pas nécessairement celui de l’origine.
Erreurs courantes
Relancer en boucle peut rencontrer des limites d’émission. Une émission manuelle réussie ne prouve pas un futur renouvellement automatique. Ne masquez pas une exclusion nécessaire par une réinclusion globale.
Recommandations en production
Activez les notifications d’échec et avertissement, vérifiez une exécution AutoSSL planifiée ultérieure et surveillez l’expiration indépendamment. La preuve complète de renouvellement exige d’observer une émission ultérieure avec une nouvelle date ; conservez jusque-là ce contrôle comme action de suivi.
Sources : cPanel, Manage AutoSSL, Let’s Encrypt, méthodes de validation.