Lorsque vous configurez ou renouvelez des certificats SSL à l’aide du protocole ACME, il n’est pas rare de rencontrer des erreurs cryptiques qui interrompent le processus. Ce guide vous présente les problèmes les plus courants liés à l’ACME, explique ce qu’ils signifient réellement et vous montre exactement comment les résoudre. Que vous installiez un nouveau certificat, que vous automatisiez les renouvellements ou que vous déboguiez un échec de validation, c’est par ici qu’il faut commencer.
Liaison de compte externe manquante ou invalide
Cette erreur se produit lorsque le serveur ACME requiert un External Account Binding (EAB), mais que votre client n’a pas envoyé d’informations d’identification valides ou qu’il les a complètement ignorées. L’EAB est un moyen de prouver que vous êtes autorisé à utiliser un serveur ACME particulier.
Comment y remédier ?
- Vérifiez à nouveau votre Key ID et votre clé HMAC: Assurez-vous que les deux sont corrects et correspondent exactement à ce qui a été fourni. Pas d’espaces cachés ni de retours à la ligne.
- Utilisez l’URL correcte de l’annuaire ACME: Certains clients vous permettent de passer –server. Ne mélangez pas les URLs de production et de staging.
- Ajoutez les drapeaux EAB: Si vous utilisez
acme.sh, les drapeaux devraient ressembler à ceci : –eab-kid –eab-hmac-key - Mettez à jour votre client ACME: Si votre client est obsolète, mettez-le à jour. Les versions plus récentes prennent mieux en charge les VAE.
Le compte n’existe pas
L’erreur urn :ietf:params:acme:error:accountDoesNotExist apparaît lorsque votre client ACME tente d’utiliser une clé de compte locale (celle stockée dans son dossier de configuration) que l’autorité de certification ne reconnaît pas.
En clair, votre client ACME fait référence à un compte qui n’existe pas ou qui a été supprimé du côté de l’autorité de certification. Cette situation est fréquente lorsque vous réinstallez le client, déplacez des serveurs ou passez d’un point d’extrémité de production à un point d’étape.
Comment y remédier ?
1. Réenregistrez votre compte ACME: Utilisez vos identifiants EAB (External Account Binding) corrects lors de l’enregistrement.
Exemple pour acme.sh :
acme.sh --register-account \
--server https://acme.your-ca.com/v2/DV \
--eab-kid YOUR_EAB_KID \
--eab-hmac-key YOUR_EAB_HMAC_KEY \
--accountemail [email protected]2. Vérifiez l’URL du serveur ACME: Assurez-vous que vous vous enregistrez bien auprès du point d’accès correspondant à votre commande.
3. Évitez de réutiliser les fichiers de compte: Ne déplacez pas les fichiers account.conf ou les clés de compte d’un serveur ou d’un client à l’autre, sauf si vous êtes sûr à 100 % qu’ils sont valables pour la même autorité de certification et le même environnement.
Mauvais nonce ou erreur d’anti-rejeu
Votre client ACME a envoyé une requête en utilisant un nonce (jeton à usage unique de l’autorité de certification) qui a déjà été utilisé, qui a expiré ou qui n’est pas valide. Le serveur le bloque pour empêcher les attaques par rejeu. L’erreur urn :ietf:params:acme:error:badNonce est généralement un problème temporaire causé par un mauvais timing, des requêtes retardées ou un décalage d’horloge.
Comment y remédier ?
1. Réessayez simplement la requête: La plupart des clients ACME (comme acme.sh) réessayent automatiquement lorsqu’ils obtiennent une erreur badNonce. Si ce n’est pas le cas, relancez votre dernière commande manuellement. Elle devrait fonctionner à la deuxième tentative.
2. Synchronisez l’horloge de votre serveur: Un décalage de l’heure du système peut entraîner des erreurs de relecture. Exécutez :
timedatectl status
timedatectl set-ntp trueOu assurez-vous que ntpd ou chronyd fonctionne correctement.
3. Vérifiez les délais du proxy ou du CDN: Si vous êtes derrière Cloudflare, un équilibreur de charge ou un proxy lent, cela peut retarder vos requêtes suffisamment pour invalider le nonce. Essayez de le contourner temporairement.
Un identifiant demandé n’a pas été délégué
Lorsque l’erreur urn :ietf:params:acme:error:rejectedIdentifier apparaît, le serveur ACME a rejeté un ou plusieurs des noms de domaine que vous avez essayé de valider. C’est généralement parce que :
- Le domaine n’existe pas dans le DNS public
- Aucun enregistrement DNS ne pointe vers votre serveur.
- Le domaine n’est pas autorisé à émettre des certificats.
En d’autres termes, l’autorité de certification ne peut pas vérifier que vous possédez ou contrôlez ce domaine.
Comment y remédier ?
1. Utilisez le format correct dans votre commande: N’incluez que le nom de domaine, pas de protocole, de barres obliques ou d’URL complètes.
- Correct: -d example.com
- Faux: -d http://example.com
2. Vérifiez que le domaine existe et se résout. Exécutez :
dig example.com +shortS’il n’y a pas de sortie, c’est que votre domaine n’est pas encore en ligne, corrigez d’abord vos paramètres DNS.
2. Faites correspondre votre commande ACME: Si vous utilisez un certificat ACME commercial, assurez-vous que le domaine pour lequel vous émettez le certificat figure dans la commande originale. Vous ne pouvez pas ajouter des domaines à la volée. Ils doivent être approuvés au préalable.
3. Faites attention aux fautes de frappe et aux confusions de sous-domaines: Vérifiez deux fois des éléments tels que www.example.com ou exemple.com. Ils sont traités comme des entrées distinctes.
Réponse non autorisée ou invalide
L’autorité de certification n’a pas pu vérifier la propriété de votre domaine. Le plus souvent, elle n’a pas pu accéder au fichier challenge ACME que votre client a placé sur le serveur. Il s’agit d’un problème de validation HTTP : l’autorité de certification a essayé d’accéder à votre site, mais n’a pas pu trouver ou lire le défi.
Le message d’erreur exact est urn :ietf:params:acme:error:unauthorized. Il peut également apparaître sous la forme suivante : « Réponse non valide de http://yourdomain.com/.well-known/acme-challenge/… ».
Comment y remédier ?
- Assurez-vous que votre serveur est accessible sur le port 80 (même si votre site redirige normalement vers HTTPS).
- Vérifiez le chemin webroot dans la configuration de votre client ACME. Les fichiers challenge doivent être écrits dans : /.well-known/acme-challenge/.
- Si votre serveur impose des redirections HTTPS, autorisez temporairement les requêtes HTTP simples pour ce chemin.
- Désactivez les CDN, les proxys inversés ou les pare-feux susceptibles d’interférer avec la validation HTTP externe de l’autorité de certification.
- Vérifiez les autorisations de fichiers et confirmez que le fichier de contestation est effectivement créé et accessible au public.
Token introuvable ou fichier inaccessible (404 ou 403)
Le serveur ACME a essayé de récupérer le fichier challenge HTTP, mais a obtenu une réponse 404 (Non trouvé) ou 403 (Interdit). Cela signifie que le fichier n’a pas été placé correctement, qu’il n’est pas accessible au public ou que votre serveur web en bloque l’accès.
Les messages d’erreur exacts peuvent varier. Voici ce que vous pouvez vous attendre à voir :
- Réponse non valide de http://yourdomain.com/.well-known/acme-challenge/… [404]
- Réponse non valide… [403 Forbidden] (en anglais)
- urn:ietf:params:acme:error:unauthorized
Comment y remédier ?
Vérifiez la racine du document pour le domaine et assurez-vous qu’elle correspond à l’endroit où le client ACME place le fichier : /.well-known/acme-challenge/
Confirmez que le fichier de jetons existe et qu’il est accessible à partir d’un navigateur. Vous devez pouvoir ouvrir l’URL du défi directement dans votre navigateur et voir le contenu du jeton.
Définissez des autorisations de fichiers correctes : le fichier ACME challenge et ses dossiers parents doivent être lisibles par le monde entier.
Si vous utilisez des règles .htaccess, des pare-feu ou des plugins de sécurité (comme sur WordPress), assurez-vous qu’ils ne bloquent pas l’accès au chemin /.well-known/.
Si vous obtenez 403, vérifiez également la propriété des fichiers et les restrictions SELinux/AppArmor, le cas échéant.
Le dossier de la CAA empêche la délivrance
Votre DNS contient un enregistrement CAA qui limite les autorités de certification autorisées à émettre des certificats pour votre domaine. Si l’autorité de certification que vous essayez d’utiliser ne figure pas dans la liste, elle est bloquée par défaut. Vous pouvez voir le message d’erreur suivant : urn :ietf:params:acme:error:caa
Il s’agit d’une politique au niveau du DNS, et non d’un problème de serveur. Les autorités de certification sont tenues de vérifier le CAA avant de délivrer un certificat.
Comment y remédier ?
Vérifiez la présence d’enregistrements CAA dans la zone DNS de votre domaine. Vous pouvez utiliser des outils en ligne ou la commande dig :
dig CAA yourdomain.comS’il n’y a pas d’enregistrement CAA, n’importe quelle autorité de certification peut émettre un certificat. Mais s’il y en a un, assurez-vous qu’il contient le nom exact de votre fournisseur de certificats, par exemple :
- 0 émission « sectigo.com »
- 0 issue « digicert.com »
Si vous utilisez un certificat joker, ajoutez également la ligne issuewild : 0 issuewild « sectigo.com »
Attendez quelques minutes pour la propagation du DNS, puis réessayez la commande d’ACME. Si vous n’êtes pas sûr, supprimez temporairement l’enregistrement CAA pour tester l’émission, mais uniquement si vous gérez le DNS de manière sécurisée.
Enregistrement TXT introuvable (pour les certificats Wildcard)
Les certificats Wildcard (comme *.example.com) nécessitent une validation DNS-01, la seule méthode autorisée par toutes les autorités de certification pour les domaines Wildcard.
DNS-01 fonctionne en vous demandant de créer un enregistrement TXT spécial dans le DNS : _acme-challenge.example.com
Si cet enregistrement est manquant ou n’a pas encore été propagé, vous obtiendrez cette erreur.
Exemples d’erreurs :
- urn:ietf:params:acme:error:dns : : Problème DNS : NXDOMAIN looking up TXT for _acme-challenge.example.com
- Enregistrement TXT non trouvé pour _acme-challenge.example.com
Comment y remédier ?
Dans votre fournisseur DNS, créez un enregistrement TXT :
- Nom: _acme-challenge.example.com
- Valeur: (le jeton que votre client ACME vous donne ; unique par demande)
Attendez 1 à 10 minutes pour que le DNS se propage. Certains fournisseurs prennent plus de temps. Confirmez avec la commande suivante.
dig TXT _acme-challenge.example.comVous pouvez également utiliser un outil de recherche DNS en ligne. Une fois visible, réessayez la validation.
Trop de demandes ou limite de taux dépassée
L’erreur apparaît sous la forme urn :ietf:params:acme:error:rateLimited ou 429 Too Many Requests lorsque le serveur ACME refuse de traiter votre demande parce que vous avez atteint une limite de débit.
Cela se produit généralement lorsque vous demandez trop de certificats pour le(s) même(s) domaine(s) dans un court laps de temps ou lorsque vous envoyez trop de demandes infructueuses d’affilée.
Comment y remédier ?
La plupart des limites de débit se réinitialisent automatiquement au bout d’une heure, d’un jour ou d’une semaine, en fonction de ce que vous avez fait. Si vous utilisez un script, vérifiez les journaux et corrigez les erreurs avant de réessayer. Ne faites pas de force brute à l’aveuglette, cela ne ferait qu’aggraver le blocage.
Pour les validations DNS-01, évitez les re-demandes rapides après de petites erreurs d’enregistrement TXT. Attendez la propagation du DNS. Si votre autorité de certification fournit une page d’état ou des en-têtes sur les limites de débit, vérifiez-les pour obtenir des délais de réinitialisation plus précis.
Erreurs DNS ou échecs de recherche
Si vous obtenez des messages tels que« DNS problem : NXDOMAIN looking up A for example.com » ou« Temporary failure in name resolution« , cela signifie que le serveur ACME n’a pas pu résoudre votre nom de domaine, soit parce que le domaine n’existe pas, soit parce qu’il n’est pas encore propagé, soit parce qu’il n’a pas d’enregistrements IP valides.
L’autorité de certification s’appuie sur le DNS pour vérifier que votre domaine existe et qu’il pointe vers un endroit réel. Si elle ne peut pas atteindre vos enregistrements A (IPv4) ou AAAA (IPv6), elle interrompt le processus de validation.
Cela peut se produire si :
- Votre domaine est tout nouveau et les DNS ne se sont pas encore complètement propagés.
- Vous avez oublié d’ajouter les bons enregistrements DNS
- Vous travaillez dans un réseau local ou interne sans visibilité DNS publique.
- Il y a une faute de frappe dans le nom de domaine que vous avez soumis
Comment y remédier ?
- Vérifiez que votre domaine possède des enregistrements A ou AAAA valides pointant vers votre serveur live.
- Utilisez des outils tels que dig, nslookup, ou des vérificateurs en ligne (par exemple whatsmydns.net) pour confirmer la propagation.
- Assurez-vous que vous n’utilisez pas un domaine privé ou interne. La validation ACME ne fonctionne que pour les noms pouvant être résolus publiquement.
- Attendez quelques minutes après les changements de DNS ; ils ne sont pas toujours appliqués instantanément.
Impossible de se connecter au serveur ACME
Cette erreur apparaît lorsque votre serveur ne peut pas atteindre le point de terminaison de l’API ACME. Elle peut se présenter sous la forme d’un refus de connexion, d’un dépassement de délai lors de la connexion, d’une impossibilité de connexion ou d’autres messages similaires en fonction du client ACME.
Comment y remédier ?
- Assurez-vous que votre serveur autorise les connexions HTTPS sortantes sur le port 443.
- Vérifiez les paramètres du pare-feu ou les règles du réseau sortant (en particulier dans les configurations cloud/VPS).
- Si vous utilisez un proxy, autorisez le trafic vers le domaine du serveur ACME de l’autorité de certification.
- Confirmez que votre serveur dispose d’un résolveur DNS fonctionnel.
- Testez la connectivité avec : curl https://acme.example.com (remplacez par le point de terminaison réel de votre autorité de certification).
- Redémarrez votre client ACME après avoir résolu les problèmes de réseau.
Échec du script post-renouvellement
Cette erreur apparaît après un renouvellement de certificat réussi, lorsque le script de suivi destiné à recharger votre serveur ou service web ne s’est pas exécuté correctement. En fonction de votre client ACME, vous pouvez voir des messages tels que « post-hook error », « deploy script failed » ou « command not found ».
Comment y remédier ?
- Exécutez manuellement votre script post-renouvellement pour voir ce qui se passe.
- Vérifiez les chemins d’accès aux fichiers, en particulier pour le nouveau certificat et la nouvelle clé.
- Assurez-vous que le script dispose des droits d’exécution (par exemple, chmod +x script.sh).
- Recherchez les fautes de frappe, les dépendances manquantes ou la mauvaise syntaxe des commandes.
- Si vous utilisez un crochet de déploiement ou un post-crochet, vérifiez que le client le prend en charge et qu’il est configuré correctement.
Derniers mots
Nous avons couvert les erreurs de certificat SSL les plus courantes de l’ACMS et donné des solutions rapides. Si aucune de ces solutions ne résout votre problème, exécutez votre client ACME en mode débogage. La plupart des clients fourniront des résultats plus détaillés lorsque vous activerez la journalisation. Ces informations peuvent vous aider à identifier la cause réelle de l’erreur et à rétablir le fonctionnement de votre SSL.
Economisez 10% sur les certificats SSL en commandant aujourd’hui!
Émission rapide, cryptage puissant, confiance de 99,99 % du navigateur, assistance dédiée et garantie de remboursement de 25 jours. Code de coupon: SAVE10
