gratifiant > linux.debian.user.french

Yann Serre (14/03/2019, 17h50)
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 :
=> /home/dom_com/www/

et des sous-domaines
=> /home/dom_com/ss1/www/
=> /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
DocumentRoot /home/dom_com/www
</VirtualHost>

J'active avec systemctl restart apache2

Dans cette configuration extrêmement simplifiée,
se connecte quand-même OBLIGATOIREMENT en https...

Qu'est ce que je ne vois pas ?

Merci pour vos lumières !
Yann Serre (14/03/2019, 18h30)
(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-age=500;
includeSubDomains; preload"
...
</VirtualHost>

Pourquoi le domaine est concerné ?
Alexandre Goethals (14/03/2019, 19h40)
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 certificat

- un certificat ss1.dom.com

- un certificat ss2.dom.com

?

De manière générale, à mon avis on se complique moinsla 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 :
[..]
Yann Serre (14/03/2019, 20h10)
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 :
[..]
Yann Serre (14/03/2019, 21h40)
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 (15/03/2019, 10h20)
Le 14/03/19 à 19:03, Yann Serre <debian-user-french> a écrit :
> 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, pourlui
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 - -o /dev/null

`man curl` pour le sens des options
Patrick CAO HUU THIEN (15/03/2019, 12h40)
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 - -o /dev/null


ou curl -I //dom.com ça fait pareil non ?

et pour rendre ton navigateur amnesic :


patrick
Daniel Caillibaud (15/03/2019, 12h50)
Le 15/03/19 à 10:48, Patrick CAO HUU THIEN <patrickcao_huu_thien>
a écrit :
> > curl -s -D - -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 fait 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 pourrait
ne s'appliquer qu'aux GET et pas aux HEAD).
Yann Serre (15/03/2019, 15h20)
Merci pour ces infos.
Yann
Discussions similaires