Fièrement canadien 
Vous vous connectez à cPanel ou recevez une alerte de votre hébergeur : AutoSSL n'a pas réussi à renouveler votre certificat. Ou pire, vous l'apprenez d'un visiteur qui vous signale un avertissement de sécurité sur votre site. Dans tous les cas, c'est un problème qui semble urgent mais qui est presque toujours réparable une fois que vous savez où chercher.
Ce qui est frustrant avec les échecs AutoSSL, c'est que le message d'erreur vous dit rarement ce qui ne va pas vraiment. « Validation échouée » ou « Impossible de vérifier la propriété du domaine » ne vous donne pas grand-chose. Ce qui se passe habituellement en coulisses, c'est que l'autorité de certification n'a pas pu atteindre votre serveur pour effectuer la vérification — et c'est presque toujours un problème de DNS ou d'accessibilité, pas un problème avec SSL lui-même.
Ce guide explique comment fonctionne réellement la validation AutoSSL, pourquoi elle échoue, et comment corriger chaque cause spécifique — des incompatibilités DNS et des interférences Cloudflare aux règles de pare-feu et aux limites de taux Let's Encrypt.
Résumé de la correction rapide
- Confirmer que le DNS de votre domaine pointe vers la bonne IP de serveur
- Vérifier que votre site est accessible en HTTP simple (pas seulement HTTPS)
- Désactiver temporairement le proxy Cloudflare s'il est actif
- Rechercher des enregistrements DNS conflictuels ou obsolètes
- Exécuter AutoSSL manuellement depuis WHM et lire la sortie du journal
- Vérifier les blocages par limite de taux Let's Encrypt si plusieurs tentatives ont échoué récemment
Comment fonctionne la validation AutoSSL (et pourquoi elle échoue)
Avant de passer aux corrections, il vaut la peine de comprendre exactement ce qui se passe lors d'un renouvellement AutoSSL — parce qu'une fois que vous comprenez le processus, les causes d'échec deviennent évidentes.
AutoSSL utilise une méthode appelée validation de domaine HTTP-01 (lorsqu'on utilise Let's Encrypt ou le niveau DV de Sectigo). Voici la séquence :
- Le système AutoSSL de cPanel contacte l'autorité de certification et demande un nouveau certificat pour votre domaine
- L'autorité de certification génère un token unique et demande à AutoSSL de le placer à une URL spécifique sur votre serveur, quelque chose comme
http://votredomaine.com/.well-known/acme-challenge/[token] - AutoSSL place ce fichier token sur votre serveur
- L'autorité de certification fait ensuite une requête HTTP à cette URL depuis ses propres serveurs pour vérifier que le fichier est présent
- Si elle peut atteindre le fichier et que le token correspond, la validation réussit et le certificat est émis
- Si quoi que ce soit empêche l'autorité d'atteindre cette URL — mauvais DNS, pare-feu, redirection, proxy — la validation échoue et aucun certificat n'est émis
Cela signifie que les échecs AutoSSL ne sont presque jamais un problème de configuration SSL sur votre serveur. C'est un problème d'accessibilité du domaine. L'autorité de certification n'a tout simplement pas pu passer pour vérifier la propriété.
Étape 1 : Vérifier que votre DNS pointe vers le bon serveur
C'est la cause la plus fréquente de loin. L'enregistrement A de votre domaine doit pointer vers l'adresse IP du serveur où se trouve votre compte cPanel. S'il pointe vers un ancien serveur, une mauvaise IP, ou rien du tout, la requête de validation de l'autorité de certification n'atteindra jamais votre serveur.
Pour vérifier votre résolution DNS actuelle, ouvrez un terminal et exécutez :
dig votredomaine.com +short
ou utilisez un outil en ligne comme la recherche DNS de MXToolbox. L'IP retournée doit correspondre exactement à l'IP de votre serveur.
Pour trouver l'IP correcte de votre serveur :
- Connectez-vous à cPanel et cherchez l'« Adresse IP partagée » dans la barre latérale des informations générales sur la droite de l'écran d'accueil
- Dans WHM, elle est listée sous Configuration du serveur ou dans le résumé du compte
- Dans votre espace client WHMCS, accédez à Mes services, cliquez sur votre forfait d'hébergement et l'IP du serveur est indiquée dans les détails du produit
Si l'IP de votre recherche DNS ne correspond pas à l'IP de votre serveur, voilà votre problème. Mettez à jour l'enregistrement A dans votre panneau de gestion DNS avec l'IP correcte et attendez la propagation avant de relancer AutoSSL.
Étape 2 : Vérifier que votre site est accessible via HTTP
La validation AutoSSL utilise le HTTP simple, pas le HTTPS. Cela surprend beaucoup de gens. Même si votre site fonctionne parfaitement en HTTPS, si quelque chose bloque ou redirige les requêtes HTTP, AutoSSL échouera.
Ouvrez un navigateur ou utilisez curl pour tester l'accès HTTP simple :
curl -I http://votredomaine.com/.well-known/acme-challenge/test
Vous pourriez obtenir une réponse 404, ce qui est correct — cela signifie simplement que le fichier n'existe pas encore, mais confirme que l'accès HTTP fonctionne. Ce que vous ne voulez pas voir, c'est un délai d'expiration de connexion, une erreur 403 Accès interdit, ou une redirection vers un endroit autre que votre serveur.
Ce qui bloque couramment la validation HTTP :
- Redirections HTTPS forcées dans .htaccess : Si votre fichier .htaccess redirige tout le trafic HTTP vers HTTPS avant que le token de validation puisse être servi, la requête de l'autorité de certification est redirigée et la vérification échoue. Vous pouvez ajouter une exception pour le répertoire .well-known (plus de détails ci-dessous).
- Règles de pare-feu bloquant le port 80 : Si le pare-feu de votre serveur bloque les connexions entrantes sur le port 80, la requête de validation ne peut pas passer. Le port 80 doit être ouvert même si vous redirigez les visiteurs vers HTTPS.
- Mode maintenance ou protection par mot de passe : Si votre site est en mode maintenance ou derrière une authentification HTTP basique, les requêtes de validation recevront une réponse non-200 et échoueront.
- Règles ModSecurity : Certaines règles WAF peuvent bloquer les requêtes vers le répertoire .well-known comme fausse alerte.
Si vous avez une redirection globale HTTP vers HTTPS dans .htaccess, vous pouvez ajouter une exception pour la validation AutoSSL en plaçant ceci avant vos règles de redirection :
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Cela indique à Apache de ne pas appliquer la redirection HTTPS pour tout ce qui se trouve dans le chemin .well-known, là où AutoSSL place ses tokens de validation.
Étape 3 : Désactiver le proxy Cloudflare pendant le renouvellement
Si votre domaine utilise le proxy Cloudflare (icône de nuage orange), c'est l'une des raisons les plus courantes pour lesquelles AutoSSL échoue silencieusement. Voici ce qui se passe : lorsque l'autorité de certification tente d'accéder au token de validation à http://votredomaine.com/.well-known/acme-challenge/..., la requête atteint les serveurs Cloudflare au lieu des vôtres. Cloudflare peut mettre en cache une réponse, retourner une erreur, ou se comporter d'une manière qui ne correspond pas à ce qu'attend l'autorité de certification — faisant échouer la validation même si votre serveur est en parfait état.
La correction est simple :
- Connectez-vous à Cloudflare et allez dans l'onglet DNS de votre domaine
- Trouvez l'enregistrement A pour votre domaine racine (@) et www
- Cliquez sur l'icône de nuage orange pour basculer en gris (mode DNS uniquement)
- Sauvegardez la modification et attendez deux à trois minutes
- Accédez à WHM et exécutez AutoSSL manuellement (voir Étape 5)
- Une fois le certificat renouvelé avec succès, réactivez le proxy Cloudflare
Si vous ne souhaitez pas désactiver le proxy à chaque exécution d'AutoSSL, vous pouvez configurer le mode SSL de Cloudflare sur « Complet » ou « Complet (strict) » et installer le certificat sur votre serveur d'origine. De cette façon, Cloudflare gère le SSL côté visiteur indépendamment d'AutoSSL, bien qu'AutoSSL s'occupe toujours du certificat d'origine.
Étape 4 : Vérifier les enregistrements DNS conflictuels
Même lorsque votre enregistrement A principal est correct, d'autres enregistrements DNS peuvent perturber la validation. Voici ce qu'il faut rechercher :
Enregistrements AAAA conflictuels
Si votre domaine possède un enregistrement AAAA (IPv6) pointant vers une adresse qui n'est pas votre serveur, l'autorité de certification peut essayer de valider via IPv6 et échouer. À moins que votre serveur ne soit réellement configuré pour IPv6, supprimez tout enregistrement AAAA ou assurez-vous qu'ils pointent vers la bonne adresse IPv6.
Pour vérifier les enregistrements AAAA :
dig AAAA votredomaine.com +short
Si cela retourne une IP qui n'est pas votre serveur, supprimez cet enregistrement de votre panneau DNS.
Enregistrements CAA restreignant l'autorité de certification
Les enregistrements CAA (Certification Authority Authorization) spécifient quelles autorités de certification sont autorisées à émettre des certificats pour votre domaine. Si vous avez un enregistrement CAA qui n'inclut pas Let's Encrypt ou Sectigo (selon le fournisseur AutoSSL utilisé par votre hébergeur), toutes les tentatives d'émission de certificats seront bloquées.
Vérifier les enregistrements CAA :
dig CAA votredomaine.com +short
Si vous voyez un enregistrement CAA qui n'autorise que, disons, DigiCert, et que votre AutoSSL utilise Let's Encrypt, vous devez soit ajouter une entrée autorisant Let's Encrypt, soit supprimer entièrement la restriction CAA. Un enregistrement CAA permissif pour Let's Encrypt ressemble à :
votredomaine.com. CAA 0 issue "letsencrypt.org"
Enregistrements de sous-domaines anciens ou obsolètes
AutoSSL ne renouvelle pas seulement le certificat pour votre domaine racine — il essaie de couvrir tous les sous-domaines associés à votre compte cPanel (www, mail, webmail, cpanel, etc.). Si l'un de ces sous-domaines possède des enregistrements A obsolètes pointant vers un serveur différent, la validation pour ces sous-domaines échouera et AutoSSL peut refuser d'émettre un certificat du tout plutôt que d'en émettre un partiel.
Examinez tous les enregistrements DNS de votre domaine et supprimez ou mettez à jour tous les sous-domaines qui ne pointent pas activement vers votre serveur actuel.
Étape 5 : Exécuter AutoSSL manuellement et lire les journaux
Une fois que vous avez traité les causes probables ci-dessus, il est temps de déclencher AutoSSL manuellement et de voir exactement ce qui se passe. Les journaux sont vraiment utiles ici — ils vous diront précisément quel domaine ou sous-domaine a échoué et pourquoi.
Exécuter AutoSSL depuis WHM
- Connectez-vous à WHM (généralement à votredomaine.com:2087 ou serveur.votredomaine.com/whm)
- Dans la barre de recherche de gauche, tapez « AutoSSL » et cliquez sur Gérer AutoSSL
- Cliquez sur l'onglet Gérer les utilisateurs
- Trouvez le compte cPanel que vous souhaitez renouveler et cliquez sur Exécuter AutoSSL
- Le processus s'exécute en arrière-plan — cliquez sur l'onglet Journaux pour suivre la progression en temps réel
Exécuter AutoSSL depuis cPanel (accès limité)
Si vous n'avez accès qu'à cPanel (pas WHM), accédez à Statut SSL/TLS sous la section Sécurité. Cela affiche l'état actuel du certificat pour chaque domaine et sous-domaine. Il y a également un bouton pour exécuter AutoSSL depuis ici, bien que le détail du journal soit plus limité que depuis WHM.
Lire la sortie du journal
Le journal AutoSSL est l'outil de diagnostic le plus utile disponible. Les points clés à rechercher :
- « Le domaine a résolu vers une adresse IP... » — indique quelle IP la vérification de validation a trouvée. Si elle ne correspond pas à votre serveur, votre DNS est incorrect.
- « HTTP DCV : Le système a échoué... » — la validation du contrôle de domaine HTTP a échoué. Quelque chose bloque le port 80 ou le chemin .well-known.
- « Limite de taux dépassée » — Let's Encrypt a temporairement bloqué d'autres tentatives d'émission. Voir Étape 6.
- « L'autorité de certification a retourné l'erreur suivante » — suivi d'un message d'erreur spécifique de Let's Encrypt ou Sectigo qui pointe généralement directement vers le problème.
Étape 6 : Vérifier les limites de taux Let's Encrypt
Si AutoSSL échoue et réessaie de manière répétée, vous avez peut-être atteint les limites de taux de Let's Encrypt. Let's Encrypt autorise un maximum de 5 émissions de certificats par domaine enregistré par semaine. Chaque tentative échouée qui a suffisamment avancé dans le processus peut compter contre cette limite.
Vous pouvez vérifier si vous avez atteint la limite de taux en visitant https://crt.sh/?q=votredomaine.com. Cela affiche tous les certificats émis pour votre domaine auprès de toutes les autorités. Si vous voyez de nombreuses entrées récentes de Let's Encrypt dans les sept derniers jours, c'est un signe que vous avez atteint la limite de taux.
Si vous êtes limité, vous avez deux options :
- Attendre. La fenêtre de limite de taux est de sept jours à partir de la première tentative échouée. Une fois que c'est passé, corrigez d'abord le problème sous-jacent, puis laissez AutoSSL s'exécuter.
- Changer temporairement de fournisseur AutoSSL. Si votre WHM dispose de Sectigo (anciennement Comodo) AutoSSL comme fournisseur alternatif, vous pouvez basculer dessus en attendant que la limite de taux Let's Encrypt se réinitialise. Accédez à WHM, Gérer AutoSSL, et vérifiez l'onglet Fournisseurs.
Gestion d'AutoSSL
Si votre hébergement est géré via notre portail client, vous pouvez consulter l'état de votre certificat SSL et demander une intervention manuelle directement depuis votre espace client sans avoir besoin d'accéder à WHM ou cPanel.
Accédez à Mes services, cliquez sur votre forfait d'hébergement et cherchez la section SSL/Certificat. Si votre certificat est expiré ou ne parvient pas à se renouveler, ouvrez un ticket de support directement depuis cette page en incluant votre nom de domaine. Notre équipe peut exécuter AutoSSL côté serveur, consulter les journaux et résoudre tout problème de configuration nécessitant un accès au niveau du serveur.
Causes courantes en un coup d'œil
Domaine ne pointant pas vers le bon serveur
L'enregistrement A dans votre DNS pointe vers une IP différente de celle du serveur où votre compte cPanel est hébergé. C'est la cause la plus fréquente. Correction : mettez à jour l'enregistrement A.
Proxy Cloudflare interceptant la validation
Le nuage orange dans Cloudflare achemine la requête de validation de l'autorité de certification loin de votre véritable serveur. Correction : basculez temporairement en mode DNS uniquement pendant le renouvellement AutoSSL.
Accès HTTP bloqué ou redirigé
Le port 80 est fermé, une règle de pare-feu bloque l'accès, ou une redirection .htaccess intercepte la requête de validation avant qu'elle puisse être servie. Correction : ouvrez le port 80 et ajoutez une exception .well-known à vos règles de redirection.
Enregistrements AAAA ou CAA conflictuels
Des enregistrements IPv6 pointant vers un serveur inexistant ou incorrect, ou des enregistrements CAA restreignant les autorités de certification pouvant émettre pour votre domaine. Correction : supprimez les enregistrements AAAA incorrects et assurez-vous que vos enregistrements CAA autorisent votre fournisseur AutoSSL.
Incompatibilité DNS de sous-domaine
AutoSSL tente de couvrir tous les sous-domaines de votre compte. Si un sous-domaine possède un enregistrement DNS obsolète, l'ensemble du renouvellement peut échouer. Correction : auditez et nettoyez les enregistrements DNS des sous-domaines.
Limite de taux Let's Encrypt
Trop de tentatives d'émission échouées en peu de temps. Correction : attendez la fenêtre de sept jours et résolvez le problème sous-jacent avant de réessayer.
Pare-feu serveur bloquant le port 80
Même avec tout le reste en ordre, si le pare-feu du serveur (CSF, iptables) bloque les connexions entrantes sur le port 80, la validation ne peut pas se terminer. Le port 80 doit être ouvert même si votre site redirige tous les visiteurs vers HTTPS.
Quand contacter le support?
La plupart des échecs AutoSSL peuvent être résolus en suivant les étapes ci-dessus. Mais certaines situations nécessitent réellement un accès au niveau du serveur pour être diagnostiquées :
- Les journaux AutoSSL montrent la bonne IP et l'accès HTTP semble fonctionner, mais la validation échoue toujours
- Le message d'erreur fait référence à un problème de configuration serveur plutôt qu'à un problème de DNS ou d'accessibilité
- Vous observez un comportement différent pour différents sous-domaines sans explication DNS évidente
- Des règles ModSecurity ou du pare-feu CSF sont impliquées et vous n'avez pas accès pour les modifier
- Votre certificat a expiré et vous avez besoin d'une restauration immédiate pendant que le problème sous-jacent est résolu
Ouvrez un ticket de support en incluant votre nom de domaine et une copie de la sortie du journal AutoSSL si vous l'avez. La sortie du journal seule réduit généralement considérablement le temps de diagnostic.
Gotekky
Besoin d’aide pour choisir la prochaine étape?
Décrivez ce que vous observez et le résultat recherché. Nous identifierons si un service géré, un projet défini ou une évaluation technique payante est la bonne prochaine étape.