Web &mdash; Jélatine https://bla.calut.fr/djelouze/tag:Web Partage d'expériences d'autohébergement et autres aventures trépidantes. Sat, 30 May 2026 10:17:09 +0200 Configuration SSL - les galères d'un naïf https://bla.calut.fr/djelouze/configuration-ssl-les-galeres-dun-naif <![CDATA[Nextcloud et Pelican sont sur un bateau. Le https de Pelican tombe à l'eau, qui l'a poussé ? Contexte J'ai un VPS chez Hetzner et mon nom de domaine chez Gandi. Par confort d'utilisation, c'est une Fedora qui tourne sur le VPS. Après plusieurs années d'utilisation d'une instance Nextcloud sur un Simple Hosting Gandi, j'ai voulu passer au niveau supérieur et gérer un serveur intégralement. La migration s'est plutôt bien passée : j'ai maintenant une instance Nextcloud sur mon VPS et j'y ai retrouvé toutes mes données. Le serveur http est Apache, encore une fois pour confort personnel. J'ai directement configuré Nextcloud pour être servi via https en utilisant les outils recommandés dans la documentation de Nextcloud, en particulier certbot pour générer un certificat Let's encrypt. Sans mettre les mains dans le cambouis, j'ai une configuration qui semble opérationnelle. Une redirection permanente permet, en bonus, de servir uniquement du https quand le navigateur pointe vers http. Le début des problèmes Ce modeste blog vous est généré grâce à Pelican (cf À propos). Il s'agit donc d'un site statique, tout ce qu'il y a de plus basique à gérer pour un serveur Apache. Aucun inconvénient à ce qu'il cohabite sur le même serveur que Nextcloud, d'autant que je voulais justement faire interagir les deux. Je me retrouve alors avec deux racines de site : /var/www/html/nextcloud /var/www/html/pelican J'ajoute un fichier de configuration pour le site .../pelican en me basant sur /etc/httpd/conf.d/nextcloud.conf mais en gardant uniquement ce que je connais : la configuration de Nextcloud a été plutôt transparente, et je ne maitrise pas les sections concernant les réécriture d'URL et les proxy. Tout au plus, je sais que je n'en ai pas besoin pour un site de simple facture. Ce qui donne : VirtualHost :80 DocumentRoot /var/www/html/pelican/ ServerName djelly.calut.fr Redirect permanent / https://djelly.calut.fr/ Directory /var/www/html/pelican/ Require all granted AllowOverride All Options FollowSymLinks MultiViews /Directory /VirtualHost J'ai alors dans mes fichiers de configuration http un pelican.conf (ci0-dessus) et un nextcloud.conf qui ressemble à celui-ci, mais pointant vers le DocumentRoot correct et un sous-domaine différent de djelly. Nul doute que les yeux avertis auront déjà repéré une bévue, mais ce n'est pas mon cas. Constat amiable Après redémarrage du serveur apache sudo service httpd restart, la partie nextcloud est toujours fonctionnelle : http://... renvoie bien vers https://..., et les différentes synchronisations en place (contact sur Android, calendrier, fichiers en local) sont toujours actives. Par contre, http://djelly.calut.fr redirige bien vers https://djelly.calut.fr, mais c'est le index.php de Nextcloud qui est affiché ! À noter que la navigation sur le site nextcloud à partir de ce sous-domaine est impossible : Accès à partir d'un domaine non approuvé Veuillez contacter votre administrateur. Si vous êtes un administrateur, éditez la variable "trusteddomains" dans le fichier config/config.php comme l'exemple dans le fichier config/config.sample.php. Vous trouverez d'autres informations sur la configuration dans la documentation . Je renomme nextcloud.conf en nextcloud.conf.old puis redémarre le service httpd (de cette manière, il ne prendra pas en compte la configuration nextcloud). J'avais dans l'idée que http://xxx.calut.fr ne serait plus accessible. Que nenni ! Il renvoie vers toujours vers https://djelly.calut.fr/index.php Donc de nouveau un fichier appartenant au DocumentRoot de nextcloud, mais avec le sous-domaine de ce site (djelly). Bien sûr, je parle de Pelican, mais il n'y est pour rien. D'ailleurs, il n'est même pas installé sur le VPS. Il ne fait que générer localement les fichiers html. Le problème se situe au niveau de la configuration Apache, j'en suis convaincu. Configuration SSL J'ai noté que les VirtualHostnextcloud et pelican sont définis pour le port 80... Mais où est donc 443, le port utilisé pour servir https ? Le répertoire /etc/httpd/conf.d contient un ssl.conf. Il ne fallait pas chercher bien loin ! On trouve assez rapidement : VirtualHost default:443 General setup for the virtual host, inherited from global configuration DocumentRoot "/var/www/html/nextcloud" ServerName xxx.calut.fr:443 ... Qu'est-ce que default:443 comparé à :80 ? "RTFM!" ! Où l'on apprend que "La chaîne default_, dont la signification est identique à celle du caractère `` [...]". Rien à voir de ce côté là, donc. Mais par contre, je n'ai aucun VirtualHost pour un ServerName djelly.calut.fr:443... et pourquoi le sous-domaine djelly renvoie sur le VirtualHost nextcloud ? Je supprime la ligne Redirect permanent / https://djelly.calut.fr/ de pelican.conf, et on commence à retrouver quelque chose de normal : http://djelly.calut.fr sert bien ce site, en http donc https://xxx.calut.fr est bien mon instance nextcloud Mais ! https://djelly.calut.fr sert toujours le index.php de nextcloud http://xxx.calut.fr sert le index.html de ce site!! Je reste dubitatif : si le VirtualHost :80 n'existe pas pour ServerName xxx.calut.fr, pourquoi est-il quand même interprété comme DocumentRoot ".../pelican" ? En testant avec un sous-domaine inexistant, j'ai bien une erreur de mon navigateur qui ne trouve pas le site. Je pense, tout candide que je suis, que ma configuration DNS entre en jeu ici. J'ai : une entrée type A pour xxx qui renvoie vers l'IP de mon VPS une entrée type A pour djelly qui renvoie vers l'IP de mon VPS pas d'entrée pour yyy Petite analyse : J'ai une erreur pour yyy.calut.fr : normal, le navigateur ne sait pas où aller chercher les fichiers http://xxx ou http://djelly renvoient tous les deux vers /var/www/html/pelican https://xxx ou https://djelly renvoient tous les deux vers /var/www/html/nextcloud On dirait que le VirtualHost de djelly écrase celui de nextcloud... La réponse ! Tout ça pour ça : en plus de ServerName, il faut aussi ServerAlias... Je récupère un certificat let's encrypt pour djelly.calut.fr et sépare le fichier ssl.conf en 3 fichiers différents : ssl.conf garde la configuration globale du SSL de ce serveur apache ssl-nextcloud.conf déclare le VirtualHost pour nextcloud ssl-pelican.conf déclare le VirtualHost pour ce site, en modifiant simplement les références à nextcloud et xxx pour correspondre à djelly. Je réactive la redirection permanente pour pelican.conf, redémarre httpd, et tout fonctionne à merveille. Ce n'était pas si compliqué. Mais je ne sais toujours pas pourquoi ServerName ne suffit pas. : Je ne suis pas passé par la migration de base de donnée documentée. J'ai simplement synchronisé mes comptes localement, installer le nouveau Nextcloud, et resynchronisé en changeant le nom du serveur. : Voir le billet Le choix d'un moteur de blog : Read The Fantastic/Funny/... Manual #Web #SSL #Pelican #Nextcloud #selfHosting ]]> Nextcloud et Pelican sont sur un bateau. Le https de Pelican tombe à l'eau, qui l'a poussé ?

Contexte

J'ai un VPS chez Hetzner et mon nom de domaine chez Gandi. Par confort d'utilisation, c'est une Fedora qui tourne sur le VPS. Après plusieurs années d'utilisation d'une instance Nextcloud sur un Simple Hosting Gandi, j'ai voulu passer au niveau supérieur et gérer un serveur intégralement. La migration s'est plutôt bien passée : j'ai maintenant une instance Nextcloud sur mon VPS et j'y ai retrouvé toutes mes données[^1]. Le serveur http est Apache, encore une fois pour confort personnel.

J'ai directement configuré Nextcloud pour être servi via https en utilisant les outils recommandés dans la documentation de Nextcloud, en particulier certbot pour générer un certificat Let's encrypt.

Sans mettre les mains dans le cambouis, j'ai une configuration qui semble opérationnelle. Une redirection permanente permet, en bonus, de servir uniquement du https quand le navigateur pointe vers http.

Le début des problèmes

Ce modeste blog vous est généré grâce à Pelican (cf À propos). Il s'agit donc d'un site statique, tout ce qu'il y a de plus basique à gérer pour un serveur Apache. Aucun inconvénient à ce qu'il cohabite sur le même serveur que Nextcloud, d'autant que je voulais justement faire interagir les deux[^2]. Je me retrouve alors avec deux racines de site :

  • /var/www/html/nextcloud
  • /var/www/html/pelican

J'ajoute un fichier de configuration pour le site .../pelican en me basant sur /etc/httpd/conf.d/nextcloud.conf mais en gardant uniquement ce que je connais : la configuration de Nextcloud a été plutôt transparente, et je ne maitrise pas les sections concernant les réécriture d'URL et les proxy. Tout au plus, je sais que je n'en ai pas besoin pour un site de simple facture. Ce qui donne :

<VirtualHost *:80>
  DocumentRoot /var/www/html/pelican/
  ServerName  djelly.calut.fr
  Redirect permanent / https://djelly.calut.fr/
  <Directory /var/www/html/pelican/>
    Require all granted
    AllowOverride All
    Options FollowSymLinks MultiViews
  </Directory>
</VirtualHost>

J'ai alors dans mes fichiers de configuration http un pelican.conf (ci0-dessus) et un nextcloud.conf qui ressemble à celui-ci, mais pointant vers le DocumentRoot correct et un sous-domaine différent de djelly. Nul doute que les yeux avertis auront déjà repéré une bévue, mais ce n'est pas mon cas.

Constat amiable

Après redémarrage du serveur apache sudo service httpd restart, la partie nextcloud est toujours fonctionnelle : http://... renvoie bien vers https://..., et les différentes synchronisations en place (contact sur Android, calendrier, fichiers en local) sont toujours actives.

Par contre, http://djelly.calut.fr redirige bien vers https://djelly.calut.fr, mais c'est le index.php de Nextcloud qui est affiché[^3] ! À noter que la navigation sur le site nextcloud à partir de ce sous-domaine est impossible :

Accès à partir d'un domaine non approuvé

Veuillez contacter votre administrateur. Si vous êtes un administrateur, éditez la variable “trusted_domains” dans le fichier config/config.php comme l'exemple dans le fichier config/config.sample.php.

Vous trouverez d'autres informations sur la configuration dans la documentation .

Je renomme nextcloud.conf en nextcloud.conf.old puis redémarre le service httpd (de cette manière, il ne prendra pas en compte la configuration nextcloud). J'avais dans l'idée que http://xxx.calut.fr ne serait plus accessible. Que nenni ! Il renvoie vers toujours vers https://djelly.calut.fr/index.php

Donc de nouveau un fichier appartenant au DocumentRoot de nextcloud, mais avec le sous-domaine de ce site (djelly). Bien sûr, je parle de Pelican, mais il n'y est pour rien. D'ailleurs, il n'est même pas installé sur le VPS. Il ne fait que générer localement les fichiers html. Le problème se situe au niveau de la configuration Apache, j'en suis convaincu.

Configuration SSL

J'ai noté que les VirtualHostnextcloud et pelican sont définis pour le port 80... Mais où est donc 443, le port utilisé pour servir https ? Le répertoire /etc/httpd/conf.d contient un ssl.conf. Il ne fallait pas chercher bien loin ! On trouve assez rapidement :

<VirtualHost _default_:443>

# General setup for the virtual host, inherited from global configuration
DocumentRoot "/var/www/html/nextcloud"
ServerName xxx.calut.fr:443
...

Qu'est-ce que _default_:443 comparé à *:80 ? “RTFM!”[^3] ! Où l'on apprend que “La chaîne _default_, dont la signification est identique à celle du caractère * [...]“. Rien à voir de ce côté là, donc. Mais par contre, je n'ai aucun VirtualHost pour un ServerName djelly.calut.fr:443... et pourquoi le sous-domaine djelly renvoie sur le VirtualHost nextcloud ?

Je supprime la ligne Redirect permanent / https://djelly.calut.fr/> de pelican.conf, et on commence à retrouver quelque chose de normal :

  • http://djelly.calut.fr sert bien ce site, en http donc
  • https://xxx.calut.fr est bien mon instance nextcloud

Mais ! – https://djelly.calut.fr sert toujours le index.php de nextcloud – http://xxx.calut.fr sert le index.html de ce site!!

Je reste dubitatif : si le <VirtualHost *:80> n'existe pas pour ServerName xxx.calut.fr, pourquoi est-il quand même interprété comme DocumentRoot ".../pelican" ? En testant avec un sous-domaine inexistant, j'ai bien une erreur de mon navigateur qui ne trouve pas le site.

Je pense, tout candide que je suis, que ma configuration DNS entre en jeu ici. J'ai :

  • une entrée type A pour xxx qui renvoie vers l'IP de mon VPS
  • une entrée type A pour djelly qui renvoie vers l'IP de mon VPS
  • pas d'entrée pour yyy

Petite analyse :

  • J'ai une erreur pour yyy.calut.fr : normal, le navigateur ne sait pas où aller chercher les fichiers
  • http://xxx ou http://djelly renvoient tous les deux vers /var/www/html/pelican
  • https://xxx ou https://djelly renvoient tous les deux vers /var/www/html/nextcloud

On dirait que le VirtualHost de djelly écrase celui de nextcloud...

La réponse !

Tout ça pour ça : en plus de ServerName, il faut aussi ServerAlias...

Je récupère un certificat let's encrypt pour djelly.calut.fr et sépare le fichier ssl.conf en 3 fichiers différents :

  • ssl.conf garde la configuration globale du SSL de ce serveur apache
  • ssl-nextcloud.conf déclare le VirtualHost pour nextcloud
  • ssl-pelican.conf déclare le VirtualHost pour ce site, en modifiant simplement les références à nextcloud et xxx pour correspondre à djelly.

Je réactive la redirection permanente pour pelican.conf, redémarre httpd, et tout fonctionne à merveille.

Ce n'était pas si compliqué. Mais je ne sais toujours pas pourquoi ServerName ne suffit pas.

[^1]: Je ne suis pas passé par la migration de base de donnée documentée. J'ai simplement synchronisé mes comptes localement, installer le nouveau Nextcloud, et resynchronisé en changeant le nom du serveur. [^2]: Voir le billet Le choix d'un moteur de blog [^3]: Read The Fantastic/Funny/... Manual

#Web #SSL #Pelican #Nextcloud #selfHosting

]]> https://bla.calut.fr/djelouze/configuration-ssl-les-galeres-dun-naif Tue, 05 Apr 2022 15:39:28 +0200