Renouvellement SSL échoué : diagnostiquer avant de relancer

Un certificat gratuit se renouvelle seul, sans que personne ne clique. Quand il expire malgré tout, la conclusion spontanée est que le service automatique est défaillant. C'est rarement exact. Le renouvellement n'est pas une action de l'hébergeur : c'est un dialogue entre l'autorité de certification et votre domaine, répété à chaque échéance, et il réussit uniquement si le domaine répond comme la première fois.

Or un site vit. Quelqu'un a changé de serveurs DNS, ajouté une règle de redirection dans le fichier .htaccess, activé un pare-feu applicatif, passé le domaine derrière un CDN ou publié un enregistrement CAA. Chacun de ces gestes est légitime, et chacun peut empêcher la validation sans que le site cesse de s'afficher. L'erreur apparaît des semaines plus tard, au moment de l'échéance, loin de la modification qui l'a provoquée. Relancer l'émission sans rien corriger ne produit que le même échec. Il faut lire le signal, trouver la condition qui a bougé, la rétablir, puis relancer une seule fois.

Pour émettre ou renouveler un certificat, l'autorité doit s'assurer que celui qui le demande contrôle réellement le domaine. Elle procède en quatre temps, et l'échec se situe toujours dans l'un d'eux.

D'abord, elle résout le nom : le DNS doit répondre et renvoyer l'adresse du bon serveur, en IPv4 comme en IPv6. Ensuite, dans la validation par fichier, elle appelle l'adresse http://votre-domaine.com/.well-known/acme-challenge/ sur le port 80 et attend le contenu précis posé par le client ACME. Troisièmement, elle consulte les enregistrements CAA du domaine pour vérifier qu'aucun ne lui interdit d'émettre. Enfin, elle suit les redirections éventuelles, mais refuse une réponse d'erreur ou une page de blocage.

Cette séquence explique l'arbre de diagnostic : pointe-t-il vers le bon serveur, le challenge est-il atteignable, une redirection ou un pare-feu l'intercepte-t-il, un CAA exclut-il l'autorité, un proxy est-il dans un mode compatible. Les étapes suivantes testent ces cinq points dans cet ordre.

C'est la cause la plus fréquente, et la plus discrète. Après une migration, un changement d'hébergeur ou un nettoyage de zone, le domaine continue de s'afficher grâce au cache ou grâce à un enregistrement A correct, tandis qu'un enregistrement AAAA, lui, désigne encore l'ancien serveur. L'autorité préfère l'IPv6 quand elle existe : elle interroge l'ancienne machine, qui ne connaît plus le fichier de challenge, et la validation échoue alors que tout semble en ordre depuis votre poste.

Le contrôle est simple : comparez dig +short A votre-domaine.com et dig +short AAAA votre-domaine.com à l'adresse réelle du serveur. Si vous n'utilisez pas l'IPv6, supprimez l'enregistrement AAAA plutôt que de le laisser pointer ailleurs. Vérifiez aussi que le domaine utilise bien les serveurs de noms où vous venez de corriger la zone ; la procédure de modification d'un enregistrement est détaillée dans le guide pour ajouter ou modifier un enregistrement DNS. Attendez ensuite la fin du délai de mise en cache annoncé par l'ancienne valeur avant de relancer.

Le challenge est une requête HTTP ordinaire que l'autorité envoie depuis ses propres serveurs. Tout ce qui répond à sa place, ou lui répond autre chose que le fichier attendu, fait échouer la validation. Trois installations posent régulièrement le problème.

La première est la redirection qui change de domaine : une règle qui renvoie tout le trafic de votre-domaine.com vers une autre adresse, y compris le chemin du challenge, envoie l'autorité chercher le fichier sur un site qui ne le contient pas. La deuxième est la règle de sécurité qui refuse les fichiers dont le nom commence par un point : elle protège .env ou .git, mais elle bloque aussi .well-known. La troisième est le pare-feu applicatif ou le filtrage par pays, qui traite l'autorité comme un visiteur inconnu et répond 403.

La parade n'est pas de désactiver la protection, mais d'exclure précisément le chemin /.well-known/acme-challenge/ des règles de redirection et de blocage. Une redirection de HTTP vers HTTPS reste acceptable, tant qu'elle conserve le chemin demandé et se termine sur le même domaine.

Un enregistrement CAA est une liste blanche publiée dans le DNS : il énumère les autorités autorisées à émettre pour le domaine. C'est un bon outil de sécurité, mais il se périme en silence. Quelqu'un publie 0 issue "une-autorite.example" lors d'un audit, puis l'hébergement passe à une autre autorité, ou AutoSSL change de fournisseur, et l'émission est refusée avec un message qui parle de CAA.

Pour corriger, lisez le résultat de dig CAA votre-domaine.com +short, identifiez l'autorité que votre service utilise (sur cPanel, la colonne Émetteur de la page Certificats SSL), puis ajoutez une ligne issue à son nom. Si vous n'avez pas besoin de cette restriction, supprimez l'enregistrement. N'oubliez pas qu'un CAA se lit en remontant l'arborescence : celui du domaine principal s'applique aux sous-domaines. Et pour un certificat qui couvre un sous-domaine générique, une ligne issuewild distincte peut être nécessaire.

Placer un domaine derrière un CDN en mode proxy change ce que voit l'autorité. Elle ne parle plus à votre serveur, mais à celui du CDN, qui peut répondre à votre place avec un certificat de bordure, une page de vérification ou une règle de sécurité propre. Selon le mode choisi, le renouvellement du certificat d'origine fonctionne ou non.

Deux réglages comptent. Le mode de chiffrement entre le CDN et l'origine d'abord : en mode souple, le CDN parle en clair à l'origine, ce qui provoque une boucle de redirection si votre serveur force HTTPS ; en mode strict, il exige un certificat d'origine valide, de sorte que l'expiration devient visible immédiatement sous la forme d'une erreur d'origine. Ensuite, les protections actives sur le chemin du challenge : il faut les lever pour /.well-known/acme-challenge/ ou passer à une validation par enregistrement DNS, qui ne dépend pas du trafic web. Pendant le diagnostic, vous pouvez aussi désactiver temporairement le proxy sur le seul enregistrement concerné, relancer l'émission, puis le réactiver.

Un renouvellement qui échoue est presque toujours le signe qu'une condition de validation a changé : le nom ne pointe plus au bon endroit, le chemin du challenge est bloqué ou détourné, une autorité est exclue, un proxy s'est glissé entre elle et le serveur. L'ordre de lecture est constant : résolution DNS, accès au port 80, réponse au chemin du challenge, enregistrement CAA, mode du proxy. Une fois la cause rétablie, une seule relance suffit. Les hébergements web ServOrbit.com incluent un SSL gratuit renouvelé automatiquement ; quand la validation échoue, la cause se lit dans le journal AutoSSL et se corrige avec les commandes ci-dessus.