robin@fabre:~/blog/lets-encrypt-ovh-mutualise-redirection-ort$ ▮ MONTPELLIER · ● data & bidouilles

cat lets-encrypt-ovh-mutualise-redirection-ort.md

Let's Encrypt sur un mutualisé OVH : quand une redirection masquée bloque le certificat

Publié le 15 juillet 2026 · #ovh #ssl #letsencrypt #dns #web #tuto

Activer le SSL Let’s Encrypt gratuit sur un hébergement mutualisé OVH, c’est censé être un clic. Sur mon domaine, l’émission du certificat est restée bloquée en doing pendant presque une heure. Le coupable était bien caché — et si ton domaine utilise une « redirection visible/invisible » OVH, ce sera peut-être le tien aussi.

Le symptôme

Le certificat demandé ne sort jamais de l’état doing. Pas d’erreur explicite, rien dans les logs de l’hébergement. Le site répond pourtant normalement en HTTP.

Le diagnostic : ton domaine ne pointe pas où tu crois

Pour vérifier que le domaine servait bien mon hébergement, j’ai déposé un fichier témoin à la racine en SFTP… inaccessible depuis le web. Le domaine répondait, mais pas depuis mon hébergement.

En cause : une vieille redirection ORT (« OVH Redirect Technology », leurs redirections de zone DNS) de type invisible, configurée des années plus tôt. Concrètement, le DNS du domaine pointait vers un serveur de redirection OVH qui servait un frameset HTML masquant la cible.

Conséquence directe : le challenge HTTP de Let’s Encrypt (/.well-known/acme-challenge/…) n’atteignait jamais mon hébergement. Le certificat ne pouvait pas se valider — d’où le doing éternel.

Bonus : les redirections invisibles (masquage par frame) sont de toute façon cassées dès que la cible envoie X-Frame-Options — et impossibles à sécuriser correctement en HTTPS. Ce mécanisme est à fuir en 2026.

Le fix

Tout est faisable via l’API OVH (ou l’espace client) :

  1. Supprimer la redirection ORT sur la racine du domaine (GET /domain/zone/{zone}/redirection pour la trouver, puis DELETE).
  2. Créer les enregistrements A/AAAA vers l’IP de ton hébergement mutualisé (visible dans l’espace client, ou via GET /hosting/web/{service}), puis rafraîchir la zone.
  3. Relancer l’émission du certificat. Sur les offres en mode multi-SSL, l’endpoint classique renvoie « Web has multiple SSLs » : il faut passer par le domaine attaché — POST /hosting/web/{service}/attachedDomain/{domain}/ssl.
  4. Si tu veux conserver une redirection, fais-la servir par l’hébergement lui-même avec un .htaccess en 301 visible, en excluant /.well-known/ pour ne pas casser les renouvellements :
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/\.well-known/
RewriteRule ^(.*)$ https://cible.example/$1 [R=301,L]

Le piège dans le piège : la propagation DNS OVH

Après modification de la zone, mes POST /refresh ne faisaient pas avancer le serial SOA — resté figé 35 minutes, avec les serveurs de noms qui servaient encore l’ancienne IP. Un refresh supplémentaire a fini par incrémenter le serial et la bascule a été immédiate.

Moralité : ne te fie pas seulement à dig, vérifie le serial (GET /domain/zone/{zone}/soa) et re-déclenche un refresh s’il ne bouge pas.

En résumé

  • Un Let’s Encrypt OVH bloqué en doing = le challenge ACME n’atteint pas ton hébergement. Vérifie avec un fichier témoin.
  • Les redirections ORT invisibles détournent le domaine en amont de l’hébergement — et sont cassées par X-Frame-Options de toute façon.
  • Sur un hébergement multi-SSL, le cert se gère par domaine attaché, pas par l’endpoint SSL global.
  • Surveille le serial SOA après chaque modif de zone : la propagation OVH peut se figer silencieusement.

← cd ~/blog