# Redirection https foireuse

**URL:** <https://www.debian-fr.org/t/redirection-https-foireuse/77781>\
**Category:** Support Debian\
**Created:** [Octobre 17, 2018, 12:28 UTC](https://www.debian-fr.org/t/redirection-https-foireuse/77781 "2018-10-17T12:28:25Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Dznet](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/d/df705f/32.png) [@Dznet](https://www.debian-fr.org/u/Dznet)\
**Post date:** [Octobre 17, 2018, 12:28 UTC](https://www.debian-fr.org/t/redirection-https-foireuse/77781/1 "2018-10-17T12:28:25Z")

</div>

Bonjour,

J’ai un serveur Web sous debian, avec ISPconfig comme Webadmin  
sur ce servuer j’ai déja quelques site --\> site1, site2 site3  
Pour avoir un https, j’ai utiliser LetsEncrypt,  
Pas de soucis les trois sites fonctionne bien avec le https.  
Là ou ça bug, c’est que j’ai voulu ajouter un 4ème site --\> site4  
J’ai un https avec LetsEncrypt, mais le problème c’est que [https://site4](https://site4) montre le contenu de site1 O\_o  
Il y a une redirection, mais je n’arrive pas à l’identifier.

J’ai portant supprime le site de /etc/letsencrypt  
/live  
/archive  
/renewal

Mais rien a faire.

Dans le Vhost je ne vois rien qui permet la redirection

Merci de votre aide

Dz

---

<div class="post-metadata">

**Author:** ![sk4hrr](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/7bcc69/32.png) [@sk4hrr](https://www.debian-fr.org/u/sk4hrr)\
**Post date:** [Octobre 17, 2018, 12:55 UTC](https://www.debian-fr.org/t/redirection-https-foireuse/77781/2 "2018-10-17T12:55:45Z")

</div>

Bonjour,

Tu n’aurais pas oublié d’activer le site ?

---

<div class="post-metadata">

**Author:** ![Dznet](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/d/df705f/32.png) [@Dznet](https://www.debian-fr.org/u/Dznet)\
**Post date:** [Octobre 17, 2018, 1:13 UTC](https://www.debian-fr.org/t/redirection-https-foireuse/77781/3 "2018-10-17T13:13:53Z")

</div>

C’est ISPconfig qui active normalement

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Octobre 17, 2018, 2:27 UTC](https://www.debian-fr.org/t/redirection-https-foireuse/77781/4 "2018-10-17T14:27:10Z")

</div>

La redirection peut être configurée dans le htaccess racine du site, aussi.  
Sinon, je ne sais pas si c’est super grave niveau sécurité de nous donner les ndd réels des sites, ça aiderait peut être à diagnostiquer ?

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Octobre 17, 2018, 2:29 UTC](https://www.debian-fr.org/t/redirection-https-foireuse/77781/5 "2018-10-17T14:29:15Z")

</div>

Ah oui, et les registrar proposent des redirections de ndd, aussi, c’est peut être à vérifier.

---

<div class="post-metadata">

**Author:** ![anon96191775](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/71c47a/32.png) [@anon96191775](https://www.debian-fr.org/u/anon96191775)\
**Post date:** [Octobre 19, 2018, 6:25 UTC](https://www.debian-fr.org/t/redirection-https-foireuse/77781/6 "2018-10-19T06:25:58Z")

</div>

> [@mattotop](#):
>
> les registrar proposent des redirections de ndd, aussi, c’est peut être à vérifier.

Si je comprends bien le premier message, les 4 sites sont sur un serveur unique. Dans ce cas on peut oublier la piste du DNS.

---

<div class="post-metadata">

**Author:** ![phazon](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/a4c791/32.png) [@phazon](https://www.debian-fr.org/u/phazon)\
**Post date:** [Octobre 19, 2018, 8:51 UTC](https://www.debian-fr.org/t/redirection-https-foireuse/77781/7 "2018-10-19T20:51:08Z")

</div>

Ca ressemble beaucoup a un vhost apache qui n’a pas les bon ServerName ou ServerAlias.  
Du coup, lorsque apache ne trouve pas de vhost qui match, il présente le premier (ou le dernier je ne sais plus) qui match.

Autre piste, un systemctl reload apache2 ne suffit pas toujours, en particulier lorsqu’on touche a du SSL.  
Un systemctl stop, suivi d’un systemctl start est souvent salvateur.
