Plesk : solution pour l’erreur de certificat 400

Lors du renouvellement d’un certificat Let’s Encrypt sous Plesk, il peut arriver que la validation échoue avec une erreur 400 Bad Request. Le message ressemble souvent à ceci :

Attempting to renew cert (example.com) from /etc/letsencrypt/renewal/example.com.conf produced an unexpected error:

Failed authorization procedure.

www.example.com (http-01):
urn:ietf:params:acme:error:unauthorized ::
The client lacks sufficient authorization ::
Invalid response from
http://www.example.com/.well-known/acme-challenge/2VQAX5eA_dSyl1RB5MjfcHr9YinF8T7nw3Z6OxU5Zu4:

"<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>"Langage du code : PHP (php)

En clair, Let’s Encrypt essaye de lire un fichier de validation dans /.well-known/acme-challenge/, mais le serveur ne renvoie pas le token attendu. À la place, il renvoie une page d’erreur 400 Bad Request.

Ce n’est donc pas un problème “SSL” au sens strict. C’est d’abord un problème d’accès HTTP au fichier de challenge ACME.

Kinsta: Premium Managed WordPress hosting

Comprendre le challenge HTTP-01 de Let’s Encrypt

Lorsque Plesk demande ou renouvelle un certificat Let’s Encrypt avec le challenge HTTP-01, l’autorité de certification vérifie que le serveur répond bien sur le domaine demandé.

Pour cela, elle tente d’accéder à une URL du type :

http://example.com/.well-known/acme-challenge/TOKENLangage du code : JavaScript (javascript)

Le fichier doit être accessible publiquement sur le port 80. Let’s Encrypt précise que le challenge HTTP-01 nécessite le trafic entrant sur le port 80, et que les IP de validation ne sont pas publiées car elles peuvent changer.

Let’s Encrypt suit les redirections HTTP, jusqu’à 10 redirections, mais uniquement vers http ou https sur les ports 80 ou 443. En revanche, si une redirection crée une boucle, pointe vers un hôte incorrect, casse le Host header, passe par un proxy mal configuré, ou renvoie une page 400, la validation échoue.

Dans Plesk, cette validation est généralement gérée par l’extension Let’s Encrypt / SSL It!. Plesk peut renouveler automatiquement les certificats, mais seulement si le domaine reste accessible de l’extérieur pendant la validation.

Cause fréquente : redirection HTTP vers HTTPS dans Plesk

Dans certains cas, l’erreur vient tout simplement de la redirection automatique HTTP vers HTTPS configurée dans Plesk. Le challenge part de l’URL HTTP, Plesk redirige, puis la requête arrive sur une configuration HTTPS qui ne répond pas correctement au fichier ACME.

La solution rapide consiste à désactiver temporairement la redirection HTTP vers HTTPS, renouveler le certificat, puis la réactiver si tout fonctionne.

Dans Plesk :

ouvrez le domaine concerné ;
allez dans SSL/TLS Certificates ou SSL/TLS, selon la version de Plesk ;
décochez Redirect from http to https ;
relancez le renouvellement du certificat Let’s Encrypt ;
réactivez la redirection HTTPS après émission correcte du certificat.

Cette correction est simple, mais elle ne règle pas tous les cas. Aujourd’hui, je conseille de tester explicitement l’accès au dossier .well-known/acme-challenge avant de relancer l’émission du certificat.

Tester manuellement l’accès au challenge ACME

Avant de relancer Let’s Encrypt, créez un fichier de test dans le document root du domaine.

Exemple typique sous Plesk, à adapter au domaine :

mkdir -p /var/www/vhosts/example.com/httpdocs/.well-known/acme-challenge

echo "ok" > /var/www/vhosts/example.com/httpdocs/.well-known/acme-challenge/test.txtLangage du code : PHP (php)

Testez ensuite depuis le serveur :

curl -i http://example.com/.well-known/acme-challenge/test.txt
curl -i http://www.example.com/.well-known/acme-challenge/test.txtLangage du code : JavaScript (javascript)

Vous devez obtenir une réponse 200 OK avec le contenu ok. Si vous obtenez une erreur 400, 403, 404, une page WordPress, une page Plesk, une redirection étrange ou une page Cloudflare, Let’s Encrypt échouera probablement aussi.

Testez aussi depuis une connexion externe, pas seulement depuis le serveur. Le serveur peut résoudre le domaine différemment en local.

curl -i http://example.com/.well-known/acme-challenge/test.txtLangage du code : JavaScript (javascript)

Une fois le test terminé, supprimez le fichier :

rm -f /var/www/vhosts/example.com/httpdocs/.well-known/acme-challenge/test.txtLangage du code : JavaScript (javascript)

Vérifier les DNS du domaine

Le challenge HTTP-01 ne peut fonctionner que si le domaine pointe vers le bon serveur Plesk.

Vérifiez les enregistrements A et AAAA :

dig +short A example.com
dig +short A www.example.com

dig +short AAAA example.com
dig +short AAAA www.example.comLangage du code : CSS (css)

Si une entrée IPv6 AAAA pointe vers un ancien serveur, Let’s Encrypt peut tenter la validation en IPv6 et échouer, même si l’IPv4 est correcte. C’est un classique bien vicieux.

Vérifiez aussi la résolution publique :

dig +short A example.com @1.1.1.1
dig +short A example.com @8.8.8.8Langage du code : CSS (css)

Si vous venez de modifier les DNS, attendez la propagation selon le TTL des anciens enregistrements.

Vérifier Cloudflare ou un proxy devant Plesk

Si le domaine passe par Cloudflare ou un autre reverse proxy, celui-ci peut intercepter, rediriger ou bloquer le challenge ACME.

Vérifiez notamment :

le mode SSL/TLS Cloudflare ;
les règles de redirection HTTP vers HTTPS ;
les règles WAF ;
les Page Rules, Redirect Rules ou Configuration Rules ;
les règles qui redirigent /.well-known/ vers WordPress ;
le proxy orange cloud sur le domaine ou le sous-domaine ;
les règles qui bloquent les requêtes sans User-Agent classique.

Pour diagnostiquer rapidement, vous pouvez passer temporairement le record DNS en “DNS only” chez Cloudflare, relancer la validation, puis réactiver le proxy si nécessaire.

Autre option plus propre : créer une règle qui laisse passer /.well-known/acme-challenge/* sans redirection, sans cache agressif et sans blocage WAF.

Le plus lu : Forcer VLC à garder votre skin au démarrage

Vérifier les redirections WordPress et .htaccess

WordPress, une extension de sécurité, une extension de redirection ou une règle .htaccess peut aussi intercepter le challenge.

Dans un environnement Apache, vérifiez le fichier :

/var/www/vhosts/example.com/httpdocs/.htaccessLangage du code : JavaScript (javascript)

Évitez toute règle qui redirige /.well-known/acme-challenge/ vers WordPress, vers HTTPS de manière cassée, vers une page canonique, ou vers le domaine principal sans tenir compte du token.

Une exception Apache utile peut ressembler à ceci, à placer avant les règles WordPress :

RewriteEngine On

# Let ACME HTTP-01 challenges pass through.
RewriteRule ^\.well-known/acme-challenge/ - [L]Langage du code : PHP (php)

Pour Nginx, la logique est la même : le chemin /.well-known/acme-challenge/ doit servir les fichiers statiques directement, sans passer par WordPress ou une redirection applicative.

Vérifier les logs Plesk et Let’s Encrypt

Si l’erreur persiste, regardez les logs. Sur un serveur Linux avec Plesk, commencez par :

/var/log/plesk/panel.logLangage du code : JavaScript (javascript)

Vous pouvez suivre le log en direct pendant une tentative de renouvellement :

sudo tail -f /var/log/plesk/panel.logLangage du code : JavaScript (javascript)

Vérifiez aussi les logs du domaine :

sudo tail -f /var/www/vhosts/system/example.com/logs/access_log
sudo tail -f /var/www/vhosts/system/example.com/logs/error_logLangage du code : JavaScript (javascript)

Vous cherchez les requêtes vers :

/.well-known/acme-challenge/

Si les requêtes n’arrivent jamais sur le serveur, regardez DNS, firewall, Cloudflare ou proxy. Si elles arrivent mais renvoient 400, 403 ou 404, regardez la configuration web du domaine.

Relancer le renouvellement dans Plesk

Une fois l’accès au fichier de test validé, relancez l’émission ou le renouvellement dans Plesk :

ouvrez le domaine ;
allez dans SSL/TLS Certificates ;
sélectionnez Let’s Encrypt ;
incluez le domaine principal et www si nécessaire ;
relancez l’émission du certificat.

Si vous avez désactivé temporairement la redirection HTTP vers HTTPS, réactivez-la après renouvellement. Puis retestez :

curl -I http://example.com
curl -I https://example.comLangage du code : JavaScript (javascript)

Le site peut rediriger en HTTPS une fois le certificat valide. Le point important est que le chemin ACME reste accessible pendant les prochains renouvellements.

Quand utiliser un challenge DNS-01 ?

Si votre domaine est derrière un proxy complexe, un firewall strict, un CDN agressif, ou si le port 80 n’est pas accessible publiquement, le challenge HTTP-01 peut devenir fragile.

Dans ce cas, le challenge DNS-01 peut être plus adapté. Il valide le domaine via un enregistrement DNS TXT, et non via un fichier accessible en HTTP.

Le challenge DNS-01 est aussi nécessaire pour émettre un certificat wildcard du type :

*.example.comLangage du code : CSS (css)

Selon votre version de Plesk et vos extensions installées, cette option peut demander une intégration DNS compatible. Sinon, il faudra gérer le certificat avec un client ACME externe adapté à votre DNS.

Le plus lu : Serveur dédié : installer la dernière version d'OpenSSL sous Debian

Checklist rapide de correction

Voici la séquence que j’utilise pour corriger une erreur 400 Bad Request Let’s Encrypt sous Plesk :

# 1. Vérifier que le domaine pointe vers le bon serveur.
dig +short A example.com
dig +short A www.example.com
dig +short AAAA example.com
dig +short AAAA www.example.com

# 2. Créer un fichier de test ACME.
mkdir -p /var/www/vhosts/example.com/httpdocs/.well-known/acme-challenge
echo "ok" > /var/www/vhosts/example.com/httpdocs/.well-known/acme-challenge/test.txt

# 3. Tester en HTTP.
curl -i http://example.com/.well-known/acme-challenge/test.txt
curl -i http://www.example.com/.well-known/acme-challenge/test.txt

# 4. Surveiller les logs du domaine.
sudo tail -f /var/www/vhosts/system/example.com/logs/access_log
sudo tail -f /var/www/vhosts/system/example.com/logs/error_log

# 5. Surveiller Plesk.
sudo tail -f /var/log/plesk/panel.log

# 6. Désactiver temporairement la redirection HTTP → HTTPS dans Plesk si nécessaire.

# 7. Relancer le renouvellement Let’s Encrypt.

# 8. Nettoyer le fichier de test.
rm -f /var/www/vhosts/example.com/httpdocs/.well-known/acme-challenge/test.txtLangage du code : PHP (php)

Causes fréquentes de l’erreur 400 Let’s Encrypt sous Plesk

redirection HTTP vers HTTPS cassée ou trop agressive ;
boucle de redirection entre Plesk, WordPress, Cloudflare ou le serveur web ;
domaine www qui ne pointe pas vers le même serveur ;
entrée IPv6 AAAA incorrecte ;
Cloudflare ou proxy qui intercepte le challenge ;
règle .htaccess qui redirige /.well-known/ ;
extension WordPress de sécurité ou de redirection trop agressive ;
firewall qui bloque le port 80 ;
document root incorrect dans Plesk ;
permissions incorrectes sur le dossier .well-known.

Conclusion

L’erreur 400 Bad Request lors d’un renouvellement Let’s Encrypt sous Plesk signifie généralement que le challenge HTTP-01 n’est pas servi correctement.

La correction rapide peut consister à décocher temporairement Redirect from http to https dans Plesk, puis à relancer le renouvellement. Mais la méthode propre consiste à tester explicitement cette URL :

http://example.com/.well-known/acme-challenge/test.txtLangage du code : JavaScript (javascript)

Si elle renvoie 200 OK avec le bon contenu, Let’s Encrypt a de bonnes chances de valider le domaine. Si elle renvoie une page 400, 403, 404, WordPress, Cloudflare ou une redirection bancale, il faut corriger l’accès HTTP avant de relancer le certificat.

Le certificat SSL se renouvelle en HTTPS, mais sa validation HTTP-01 commence bien par le port 80. Oui, c’est un peu contre-intuitif. Mais une fois qu’on le sait, le dépannage devient beaucoup moins mystique.

Sources

Report a typo

Facebook Tweet Pin LinkedIn

4 pensées sur “Plesk : corriger l’erreur 400 Let’s Encrypt au renouvellement SSL”

rvcraft

13 avril à 8:50

Un ENORME merci pour ta solution, j’allais devenir fou :)
Répondre
- Matt
  
  14 avril à 9:53
  
  Je suis content que cela t’ait aidé rvcraft :)
  Répondre
Antoine

12 juin à 23:52

Hello,
Merci aussi pour cette solution, je galérais depuis des jours là-dessus !!!
Il fallait en effet la trouver cette soluce pour cet échec de l’autorisation pour le domaine avec Let’s Encrypt.
je me perdais en conjonctures diverses, et voilà qu’il suffisait de décocher une case !
MERCI encore !
Antoine
Répondre
- Matt
  
  28 juin à 22:57
  
  Bonjour Antoine,
  
  Je t’en prie, je suis content que cela ait pu t’aider!
  Répondre

Plesk : corriger l’erreur 400 Let’s Encrypt au renouvellement SSL