J'utilise un domaine qu'on appellera "dom.com" dans ce message sur
lequel je peux faire des tests.
Ce domaine fonctionne correctement depuis plusieurs années. Les
renouvellements de certificats (Let's encrypt) se passent normalement (CRON)
Donc on a juste :
https://www.dom.com/ => /home/dom_com/www/
et des sous-domaines
https://ss1.dom.com/ => /home/dom_com/ss1/www/
https://ss2.dom.com/ => /home/dom_com/ss2/www/
Pour le moment chaque racine www a un dossier physique .well-known (le
but sera de centraliser, par exemple dans /var/.well-known/, mais on
n'en est pas là).
Je crée un nouveau sous-domaine ss3
Même paramétré uniquement sur le port 80, ss3.dom.com ne veut se
connecter qu'en https.
Après une heure à ne plus rien comprendre, je décide de désactiver tous
les sous-domaines existants de Apache2/sites-enabled pour ne pas être
pollué. Et de mettre dom.com en port 80 uniquement.
Voici mon nouveau Apache2/sites-available pour dom.com :
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Yann Serre
(suite) Je suppose que je suis dans le cas d'une politique HSTS. Mais si Apache2 ne le mentionne pas explicitement avec : <VirtualHost *:443> ... Header always set Strict-Transport-Security "max-ageP0; includeSubDomains; preload" ... </VirtualHost> Pourquoi le domaine est concerné ?
(suite)
Je suppose que je suis dans le cas d'une politique HSTS.
Mais si Apache2 ne le mentionne pas explicitement avec :
(suite) Je suppose que je suis dans le cas d'une politique HSTS. Mais si Apache2 ne le mentionne pas explicitement avec : <VirtualHost *:443> ... Header always set Strict-Transport-Security "max-ageP0; includeSubDomains; preload" ... </VirtualHost> Pourquoi le domaine est concerné ?
Alexandre Goethals
Bonjour, peut-être y a-t-il d'autres éléments de configuration apac he (dans /etc/apache2/conf-enabled/ par exemple) ? Petite question au passage: est-ce que vous avez un certificat wildcard unique *.dom.com, ou vous avez : - un certificat www.dom.com - un certificat ss1.dom.com - un certificat ss2.dom.com ? De manière générale, à mon avis on se complique moins la vie, à moyen/long terme lorsque l'on crée les certificats Let's Encrypt en --manual (certbot ne vas pas toucher aux conf Apache/Nginx), au moins on sait ce que l'on fait / ce que l'on a fait. Le 14/03/2019 à 16:42, Yann Serre a écrit :
Bonjour, J'utilise un domaine qu'on appellera "dom.com" dans ce message sur lequel je peux faire des tests. Ce domaine fonctionne correctement depuis plusieurs années. Les renouvellements de certificats (Let's encrypt) se passent normalement (CRON) Donc on a juste : https://www.dom.com/ => /home/dom_com/www/ et des sous-domaines https://ss1.dom.com/ => /home/dom_com/ss1/www/ https://ss2.dom.com/ => /home/dom_com/ss2/www/ Pour le moment chaque racine www a un dossier physique .well-known (le but sera de centraliser, par exemple dans /var/.well-known/, mais on n'en est pas là). Je crée un nouveau sous-domaine ss3 Même paramétré uniquement sur le port 80, ss3.dom.com ne veut se connecter qu'en https. Après une heure à ne plus rien comprendre, je décide de désactiver tous les sous-domaines existants de Apache2/sites-enabled pour ne pas être pollué. Et de mettre dom.com en port 80 uniquement. Voici mon nouveau Apache2/sites-available pour dom.com : <VirtualHost *:80> ServerName dom.com ServerAlias www.dom.com DocumentRoot /home/dom_com/www </VirtualHost> J'active avec systemctl restart apache2 Dans cette configuration extrêmement simplifiée, http://www.dom.com se connecte quand-même OBLIGATOIREMENT en https ... Qu'est ce que je ne vois pas ? Merci pour vos lumières !
Bonjour,
peut-être y a-t-il d'autres éléments de configuration apac he (dans
/etc/apache2/conf-enabled/ par exemple) ?
Petite question au passage: est-ce que vous avez un certificat wildcard
unique *.dom.com, ou vous avez :
- un certificat www.dom.com
- un certificat ss1.dom.com
- un certificat ss2.dom.com
?
De manière générale, à mon avis on se complique moins la vie, à
moyen/long terme lorsque l'on crée les certificats Let's Encrypt en
--manual (certbot ne vas pas toucher aux conf Apache/Nginx), au moins on
sait ce que l'on fait / ce que l'on a fait.
Le 14/03/2019 à 16:42, Yann Serre a écrit :
Bonjour,
J'utilise un domaine qu'on appellera "dom.com" dans ce message sur
lequel je peux faire des tests.
Ce domaine fonctionne correctement depuis plusieurs années. Les
renouvellements de certificats (Let's encrypt) se passent normalement
(CRON)
Donc on a juste :
https://www.dom.com/ => /home/dom_com/www/
et des sous-domaines
https://ss1.dom.com/ => /home/dom_com/ss1/www/
https://ss2.dom.com/ => /home/dom_com/ss2/www/
Pour le moment chaque racine www a un dossier physique .well-known (le
but sera de centraliser, par exemple dans /var/.well-known/, mais on
n'en est pas là).
Je crée un nouveau sous-domaine ss3
Même paramétré uniquement sur le port 80, ss3.dom.com ne veut se
connecter qu'en https.
Après une heure à ne plus rien comprendre, je décide de désactiver
tous les sous-domaines existants de Apache2/sites-enabled pour ne pas
être pollué. Et de mettre dom.com en port 80 uniquement.
Voici mon nouveau Apache2/sites-available pour dom.com :
Bonjour, peut-être y a-t-il d'autres éléments de configuration apac he (dans /etc/apache2/conf-enabled/ par exemple) ? Petite question au passage: est-ce que vous avez un certificat wildcard unique *.dom.com, ou vous avez : - un certificat www.dom.com - un certificat ss1.dom.com - un certificat ss2.dom.com ? De manière générale, à mon avis on se complique moins la vie, à moyen/long terme lorsque l'on crée les certificats Let's Encrypt en --manual (certbot ne vas pas toucher aux conf Apache/Nginx), au moins on sait ce que l'on fait / ce que l'on a fait. Le 14/03/2019 à 16:42, Yann Serre a écrit :
Bonjour, J'utilise un domaine qu'on appellera "dom.com" dans ce message sur lequel je peux faire des tests. Ce domaine fonctionne correctement depuis plusieurs années. Les renouvellements de certificats (Let's encrypt) se passent normalement (CRON) Donc on a juste : https://www.dom.com/ => /home/dom_com/www/ et des sous-domaines https://ss1.dom.com/ => /home/dom_com/ss1/www/ https://ss2.dom.com/ => /home/dom_com/ss2/www/ Pour le moment chaque racine www a un dossier physique .well-known (le but sera de centraliser, par exemple dans /var/.well-known/, mais on n'en est pas là). Je crée un nouveau sous-domaine ss3 Même paramétré uniquement sur le port 80, ss3.dom.com ne veut se connecter qu'en https. Après une heure à ne plus rien comprendre, je décide de désactiver tous les sous-domaines existants de Apache2/sites-enabled pour ne pas être pollué. Et de mettre dom.com en port 80 uniquement. Voici mon nouveau Apache2/sites-available pour dom.com : <VirtualHost *:80> ServerName dom.com ServerAlias www.dom.com DocumentRoot /home/dom_com/www </VirtualHost> J'active avec systemctl restart apache2 Dans cette configuration extrêmement simplifiée, http://www.dom.com se connecte quand-même OBLIGATOIREMENT en https ... Qu'est ce que je ne vois pas ? Merci pour vos lumières !
Yann Serre
Bonjour, C'est un Apache2 de base, avec la modification de /var/home en /home Chaque sous-domaine est nommé. Chacun a son répertoire dans /etc/letsencrypt/live/ L'origine du problème c'est que je ne PEUX plus accéder à ss3.dom.com autrement qu'en https et avec HSTS qui barre la route. Au départ je pensais que c'était juste une restriction de Firefox et Chrome. Mon dossier .well-done répond systématiquement en https et en forbidden 403. (Pour l'instant il est en 766 - root:root) Le 14/03/2019 à 18:34, Alexandre Goethals a écrit :
Bonjour, peut-être y a-t-il d'autres éléments de configuration apache (dans /etc/apache2/conf-enabled/ par exemple) ? Petite question au passage: est-ce que vous avez un certificat wildcard unique *.dom.com, ou vous avez : - un certificatwww.dom.com - un certificat ss1.dom.com - un certificat ss2.dom.com ? De manière générale, à mon avis on se complique moins la vie, à moyen/long terme lorsque l'on crée les certificats Let's Encrypt en --manual (certbot ne vas pas toucher aux conf Apache/Nginx), au moins on sait ce que l'on fait / ce que l'on a fait. Le 14/03/2019 à 16:42, Yann Serre a écrit :
Bonjour, J'utilise un domaine qu'on appellera "dom.com" dans ce message sur lequel je peux faire des tests. Ce domaine fonctionne correctement depuis plusieurs années. Les renouvellements de certificats (Let's encrypt) se passent normalement (CRON) Donc on a juste : https://www.dom.com/ =>/home/dom_com/www/ et des sous-domaines https://ss1.dom.com/ =>/home/dom_com/ss1/www/ https://ss2.dom.com/ =>/home/dom_com/ss2/www/ Pour le moment chaque racine www a un dossier physique .well-known (le but sera de centraliser, par exemple dans/var/.well-known/, mais on n'en est pas là). Je crée un nouveau sous-domaine ss3 Même paramétré uniquement sur le port 80, ss3.dom.com ne veut se connecter qu'en https. Après une heure à ne plus rien comprendre, je décide de désactiver tous les sous-domaines existants de Apache2/sites-enabled pour ne pas être pollué. Et de mettre dom.com en port 80 uniquement. Voici mon nouveau Apache2/sites-available pour dom.com : <VirtualHost *:80> ServerName dom.com ServerAliaswww.dom.com DocumentRoot /home/dom_com/www </VirtualHost> J'active avec systemctl restart apache2 Dans cette configuration extrêmement simplifiée, http://www.dom.com se connecte quand-même OBLIGATOIREMENT en https... Qu'est ce que je ne vois pas ? Merci pour vos lumières !
Bonjour,
C'est un Apache2 de base, avec la modification de /var/home en /home
Chaque sous-domaine est nommé.
Chacun a son répertoire dans /etc/letsencrypt/live/
L'origine du problème c'est que je ne PEUX plus accéder à ss3.dom.com
autrement qu'en https et avec HSTS qui barre la route. Au départ je
pensais que c'était juste une restriction de Firefox et Chrome.
Mon dossier .well-done répond systématiquement en https et en forbidden
403. (Pour l'instant il est en 766 - root:root)
Le 14/03/2019 à 18:34, Alexandre Goethals a écrit :
Bonjour,
peut-être y a-t-il d'autres éléments de configuration apache (dans
/etc/apache2/conf-enabled/ par exemple) ?
Petite question au passage: est-ce que vous avez un certificat wildcard
unique *.dom.com, ou vous avez :
- un certificatwww.dom.com
- un certificat ss1.dom.com
- un certificat ss2.dom.com
?
De manière générale, à mon avis on se complique moins la vie, à
moyen/long terme lorsque l'on crée les certificats Let's Encrypt en
--manual (certbot ne vas pas toucher aux conf Apache/Nginx), au moins on
sait ce que l'on fait / ce que l'on a fait.
Le 14/03/2019 à 16:42, Yann Serre a écrit :
Bonjour,
J'utilise un domaine qu'on appellera "dom.com" dans ce message sur
lequel je peux faire des tests.
Ce domaine fonctionne correctement depuis plusieurs années. Les
renouvellements de certificats (Let's encrypt) se passent normalement
(CRON)
Donc on a juste :
https://www.dom.com/ =>/home/dom_com/www/
et des sous-domaines
https://ss1.dom.com/ =>/home/dom_com/ss1/www/
https://ss2.dom.com/ =>/home/dom_com/ss2/www/
Pour le moment chaque racine www a un dossier physique .well-known (le
but sera de centraliser, par exemple dans/var/.well-known/, mais on
n'en est pas là).
Je crée un nouveau sous-domaine ss3
Même paramétré uniquement sur le port 80, ss3.dom.com ne veut se
connecter qu'en https.
Après une heure à ne plus rien comprendre, je décide de désactiver
tous les sous-domaines existants de Apache2/sites-enabled pour ne pas
être pollué. Et de mettre dom.com en port 80 uniquement.
Voici mon nouveau Apache2/sites-available pour dom.com :
Bonjour, C'est un Apache2 de base, avec la modification de /var/home en /home Chaque sous-domaine est nommé. Chacun a son répertoire dans /etc/letsencrypt/live/ L'origine du problème c'est que je ne PEUX plus accéder à ss3.dom.com autrement qu'en https et avec HSTS qui barre la route. Au départ je pensais que c'était juste une restriction de Firefox et Chrome. Mon dossier .well-done répond systématiquement en https et en forbidden 403. (Pour l'instant il est en 766 - root:root) Le 14/03/2019 à 18:34, Alexandre Goethals a écrit :
Bonjour, peut-être y a-t-il d'autres éléments de configuration apache (dans /etc/apache2/conf-enabled/ par exemple) ? Petite question au passage: est-ce que vous avez un certificat wildcard unique *.dom.com, ou vous avez : - un certificatwww.dom.com - un certificat ss1.dom.com - un certificat ss2.dom.com ? De manière générale, à mon avis on se complique moins la vie, à moyen/long terme lorsque l'on crée les certificats Let's Encrypt en --manual (certbot ne vas pas toucher aux conf Apache/Nginx), au moins on sait ce que l'on fait / ce que l'on a fait. Le 14/03/2019 à 16:42, Yann Serre a écrit :
Bonjour, J'utilise un domaine qu'on appellera "dom.com" dans ce message sur lequel je peux faire des tests. Ce domaine fonctionne correctement depuis plusieurs années. Les renouvellements de certificats (Let's encrypt) se passent normalement (CRON) Donc on a juste : https://www.dom.com/ =>/home/dom_com/www/ et des sous-domaines https://ss1.dom.com/ =>/home/dom_com/ss1/www/ https://ss2.dom.com/ =>/home/dom_com/ss2/www/ Pour le moment chaque racine www a un dossier physique .well-known (le but sera de centraliser, par exemple dans/var/.well-known/, mais on n'en est pas là). Je crée un nouveau sous-domaine ss3 Même paramétré uniquement sur le port 80, ss3.dom.com ne veut se connecter qu'en https. Après une heure à ne plus rien comprendre, je décide de désactiver tous les sous-domaines existants de Apache2/sites-enabled pour ne pas être pollué. Et de mettre dom.com en port 80 uniquement. Voici mon nouveau Apache2/sites-available pour dom.com : <VirtualHost *:80> ServerName dom.com ServerAliaswww.dom.com DocumentRoot /home/dom_com/www </VirtualHost> J'active avec systemctl restart apache2 Dans cette configuration extrêmement simplifiée, http://www.dom.com se connecte quand-même OBLIGATOIREMENT en https... Qu'est ce que je ne vois pas ? Merci pour vos lumières !
Yann Serre
Je suis passé de 403 à 404 Et donc trouvé ensuite une erreur de chemin. Mon certificat est dans le répertoire de dom.com et ça fonctionne... On verra si le prochain certificat se renouvellera. Merci pour vos pistes, bonne soirée.
Je suis passé de 403 à 404
Et donc trouvé ensuite une erreur de chemin.
Mon certificat est dans le répertoire de dom.com
et ça fonctionne...
On verra si le prochain certificat se renouvellera.
Merci pour vos pistes,
bonne soirée.
Je suis passé de 403 à 404 Et donc trouvé ensuite une erreur de chemin. Mon certificat est dans le répertoire de dom.com et ça fonctionne... On verra si le prochain certificat se renouvellera. Merci pour vos pistes, bonne soirée.
Daniel Caillibaud
Le 14/03/19 à 19:03, Yann Serre a éc rit :
L'origine du problème c'est que je ne PEUX plus accéder à ss3.dom.com autrement qu'en https et avec HSTS qui barre la route. Au départ je pensais que c'était juste une restriction de Firefox et Chrome.
hsts c'est effectivement au niveau du navigateur que ça se passe, pour lui dire "rappelle toi pendant xx jours que ce domaine n'existe qu'en https et qu'il ne faut jamais l'appeler en http" Pour savoir si c'est un pb de hsts (mémorisé par ton navigateur) ou autre chose (redirection coté serveur), utilise curl : curl -s -D - http://dom.com -o /dev/null `man curl` pour le sens des options -- Daniel Quelqu'un parle de tuer Zani, et Panzani...
Le 14/03/19 à 19:03, Yann Serre <debian-user-french@eml.ovh> a éc rit :
L'origine du problème c'est que je ne PEUX plus accéder à ss3.dom.com
autrement qu'en https et avec HSTS qui barre la route. Au départ je
pensais que c'était juste une restriction de Firefox et Chrome.
hsts c'est effectivement au niveau du navigateur que ça se passe, pour lui
dire "rappelle toi pendant xx jours que ce domaine n'existe qu'en https et
qu'il ne faut jamais l'appeler en http"
Pour savoir si c'est un pb de hsts (mémorisé par ton navigateur) ou autre
chose (redirection coté serveur), utilise curl :
L'origine du problème c'est que je ne PEUX plus accéder à ss3.dom.com autrement qu'en https et avec HSTS qui barre la route. Au départ je pensais que c'était juste une restriction de Firefox et Chrome.
hsts c'est effectivement au niveau du navigateur que ça se passe, pour lui dire "rappelle toi pendant xx jours que ce domaine n'existe qu'en https et qu'il ne faut jamais l'appeler en http" Pour savoir si c'est un pb de hsts (mémorisé par ton navigateur) ou autre chose (redirection coté serveur), utilise curl : curl -s -D - http://dom.com -o /dev/null `man curl` pour le sens des options -- Daniel Quelqu'un parle de tuer Zani, et Panzani...
Patrick CAO HUU THIEN
Le 15 mars 2019 a 09:14:43 +0100, Daniel Caillibaud a écrit :
hsts c'est effectivement au niveau du navigateur que ça se passe, pour lui dire "rappelle toi pendant xx jours que ce domaine n'existe qu'en https et qu'il ne faut jamais l'appeler en http" Pour savoir si c'est un pb de hsts (mémorisé par ton navigateur) ou autre chose (redirection coté serveur), utilise curl : curl -s -D - http://dom.com -o /dev/null
ou curl -I //dom.com ça fait pareil non ? et pour rendre ton navigateur amnesic : https://www.thesslstore.com/blog/clear-hsts-settings-chrome-firefox/ patrick
Le 15 mars 2019 a 09:14:43 +0100, Daniel Caillibaud a écrit :
hsts c'est effectivement au niveau du navigateur que ça se passe, pour lui
dire "rappelle toi pendant xx jours que ce domaine n'existe qu'en https et
qu'il ne faut jamais l'appeler en http"
Pour savoir si c'est un pb de hsts (mémorisé par ton navigateur) ou autre
chose (redirection coté serveur), utilise curl :
curl -s -D - http://dom.com -o /dev/null
ou curl -I //dom.com ça fait pareil non ?
et pour rendre ton navigateur amnesic :
https://www.thesslstore.com/blog/clear-hsts-settings-chrome-firefox/
Le 15 mars 2019 a 09:14:43 +0100, Daniel Caillibaud a écrit :
hsts c'est effectivement au niveau du navigateur que ça se passe, pour lui dire "rappelle toi pendant xx jours que ce domaine n'existe qu'en https et qu'il ne faut jamais l'appeler en http" Pour savoir si c'est un pb de hsts (mémorisé par ton navigateur) ou autre chose (redirection coté serveur), utilise curl : curl -s -D - http://dom.com -o /dev/null
ou curl -I //dom.com ça fait pareil non ? et pour rendre ton navigateur amnesic : https://www.thesslstore.com/blog/clear-hsts-settings-chrome-firefox/ patrick
Daniel Caillibaud
Le 15/03/19 à 10:48, Patrick CAO HUU THIEN .fr> a écrit :
curl -s -D - http://dom.com -o /dev/null
ou curl -I //dom.com ça fait pareil non ?
Non, -I ça fait une requête http HEAD, la précédente fa it un vrai GET et jette le contenu pour n'afficher que les headers (dans un cas comme ça c'est plus prudent car si y'a de la redirection coté serveur elle pour rait ne s'appliquer qu'aux GET et pas aux HEAD). -- Daniel Si on ne peut plus tricher avec ses amis, ce n'est plus la peine de jouer aux cartes. Marcel Pagnol.
Le 15/03/19 à 10:48, Patrick CAO HUU THIEN <patrick.cao_huu_thien@upmc .fr>
a écrit :
> curl -s -D - http://dom.com -o /dev/null
ou curl -I //dom.com ça fait pareil non ?
Non, -I ça fait une requête http HEAD, la précédente fa it un vrai GET et
jette le contenu pour n'afficher que les headers (dans un cas comme ça
c'est plus prudent car si y'a de la redirection coté serveur elle pour rait
ne s'appliquer qu'aux GET et pas aux HEAD).
--
Daniel
Si on ne peut plus tricher avec ses amis,
ce n'est plus la peine de jouer aux cartes.
Marcel Pagnol.
Le 15/03/19 à 10:48, Patrick CAO HUU THIEN .fr> a écrit :
curl -s -D - http://dom.com -o /dev/null
ou curl -I //dom.com ça fait pareil non ?
Non, -I ça fait une requête http HEAD, la précédente fa it un vrai GET et jette le contenu pour n'afficher que les headers (dans un cas comme ça c'est plus prudent car si y'a de la redirection coté serveur elle pour rait ne s'appliquer qu'aux GET et pas aux HEAD). -- Daniel Si on ne peut plus tricher avec ses amis, ce n'est plus la peine de jouer aux cartes. Marcel Pagnol.
