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 intéragir
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 (ci-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 "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!" ! 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 donchttps://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 apachessl-nextcloud.conf déclare le VirtualHost pour nextcloudssl-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.