Serveur Web MultiSites SSL - Virtualisation ?

Support Debian
#1

Bonjour,

Je reviens vers vous car je consulte pas mal de doc et du coup j’y perd un peu mon latin… :confused:

Mon serveur (tout neuf) est un Lenovo TS150 processeur quatre cœurs Intel Xeon E3 1225 V5 de 3.3Ghz et 8 G de RAM DDR4 2133 Mhz (que je peux augmenter si besoin).

Le serveur fera de la gestion de fichiers, web/cloud, mail. Il y aura au départ 2 sites / cloud, le premier sera consulter par 200 personnes (pas en simultané) et le seconds par 50 personnes (pas en simultané non plus). Je n’ai qu’une IP fixe.

Je me pose la question, pour le second site, de mettre en place une VM de type KVM afin de l’isoler du reste du system. De plus j’ai cru lire que faire du multisites en SSL était problématique/compliqué d’où ma réflexion de mettre en place une VM.

Qu’en pensez vous ?
Je me complique la vie avec KVM car il est finalement possible de faire du multisite en SSL ?
La VM sera-t-elle gourmande en ressource et du coup ralentira le serveur ?
La VM est elle faite pour être en production ou juste pour des tests ?
S’il vaut mieux mettre en place une VM faut il KVM ou une autre ?

Merci d’avance pour vos retours !

#2

Je ne comprends pas trop ce que tu veux faire, si c’est du pur https, ou bien un mix de site web, de ftp etc, avec une couche de sécurité SSL/TLS, mais a priori, tous les services basés sur un nom de domaine (puisque tu veux avoir deux trucs séparés sur une même ip, il faut forcément se baser sur des domaines ou sous domaines distincts), savent très bien gérer des certificats multiples.
Et même si c’est pour des raisons de sécurité, pas de raison d’utiliser une lourde VM là ou il y a moyen de chrooter/jailer.
Et si c’est pour pouvoir déplacer un service ou l’autre à un moment pour les séparer, alors c’est tous tes services qu’il faut mettre en VM, pas juste 1.

#3

Tu peux aussi te documenter sur docker qui fait la synthèse entre VM et Chroot (Jail)

1 J'aime
#4

Merci pour ta contribution mattotop,

Il y aura bien deux noms de domaine (site1.fr et site2.fr), je souhaite que les deux soit en https en effet, pour chaque site une partie “institutionnelle” sur site1.fr et un cloud en sous domaine type nextcloud.site1.fr idem pour le site2.fr.

Donc tu me conseilles de ne pas faire de VM, la création des deux sites va se gérer avec chacun leur certificat dans leur fichier de conf sans problème ?

Afin d’isoler le site2 j’ai prévu de créer un utilisateur et de mettre le fichier dans celui ci, vous êtes d’accord sur la façon de faire ?

Merci pour ton retour.

#5

J’ai un peu de mal a comprendre ce que tu cherche a faire exactement … Si tu pouvais donner un peu plus d’info sur ton projet. Tu as 2 sites sur les 2 serveurs ? Où seulement 1 site sur le premier serveur et un sous domaine sur le second ?

Pour ce qui est de Https on verra plus tard mais il ne devrais pas y avoir de problème. Si tu arrive a faire ce que tu veux en http simple le https suivra.

Pour ce qui est des VM/docker cela est recommandé si tu as plusieurs service sur une même machine, ça évite que la corruption d’un service dégrade un autre. Coté perf ne t’en fait pas tu ne devrais pas avoir de pb avec ta machine. Les CPU actuels ont des instructions spécialisé pour réduire la perte de perf des environnement virtualisés.

Fait par étape simple, on verra au fur et a mesure.

#6

Bonjour,

En effet, docker à l’aire d’être pratique. Si j’ai bien compris, et dans mon cas, je pourrais faire deux conteneurs avec chacun leur serveur lamp et donc un site par conteneur ?

Les conteneur ont chacun leur adresse ip en sous réseau ?

Merci pour ton aide ! :wink:

#7

Non je n’ai qu’un serveur sur lequel il y aura deux sites, deux noms de domaine, une ip publique ; c’est pour cela que je parle de multisites (après mes termes de profane ne sont peut être pas les bons… :fearful:)

Mon réseau :
Une box 192.168. 1.1 avec ip publique fixe xx.xx.xx.xx (DMZ) – passerelle 192.168.20.1 – serveur 192.168.20.100 – PCclients / imprimantes / scanners / 192.168.20.xx
Pour mon historique, j’ai un serveur sur ubuntu que je vais migrer sur le nouveau sur Debian. Enfin quand je dit serveur c’est juste un pc de 2010 avec un processeur de 2 G et 4 G de RAM et un disque dur… :relaxed:
Ce qui explique que je souhaite le faire migrer sur un serveur qui tienne la route, et vu que j’ai monté mon ubuntu au fur et à mesure en tatonnant par ci par là, j’aimerais pour le nouveau faire les choses proprement.

Ce nouveau serveur est à la fois serveur de fichiers (gestion des droits avec samba et acl), web pour les deux sites dont on parle (apache2, mysql, php), et je voudrait mettre en place un serveur mail.

Si on parle de conteneur, l’idéal serait de faire un conteneur pour le site1, un pour le site2, et un autre pour les mails c’est bien ça ?

Merci à vous pour votre temps et vos réponses (j’ai l’impression d’être un boulet… :cry: )

#8

Un mot d’explication.

Le client (navigateur ou autre) indique au serveur le site auquel il veut accéder dans la requête HTTP avec l’en-tête “Host:”.

En HTTPS, le client et le serveur négocient la sécurisation de la connexion SSL/TLS avant le dialogue HTTP. Lors de la négociation SSL le serveur envoie le certificat au client qui peut vérifier sa validité (date, émetteur) et s’il correspond au site demandé.

Problème avec plusieurs sites HTTPS accessibles sur une même adresse IP et un même port : au stade de la négociation SSL, le dialogue HTTP n’a pas encore eu lieu donc le serveur ne sait pas quel site le client va demander. Si chaque site a un certificat différent, le serveur ne sait donc pas quel certificat envoyer.

Il y a plusieurs solutions :

  • la solution traditionnelle : le serveur envoie toujours le même certificat qui contient en alias tous les sites HTTPS du serveur ;

  • la nouvelle solution, SNI (Server Name Indication), est une extension du protocole SSL/TLS qui permet au client d’envoyer le nom du site lors de la négociation SSL, permettant au serveur d’envoyer le certificat correspondant. Pour être effective SNI doit être supportée par le client et le serveur (voir Wikipédia pour les détails).

Il y a aussi les solutions traditionnelles basées sur l’utilisation d’une adresse IP ou d’un port différent pour chaque site. Dans le cas où on ne dispose que d’une seule adresse IP, on ne peut jouer que sur le port, de deux façons :

  • la façon traditionnelle, en indiquant le numéro port dans l’URL https://site:port/ , pas très pratique ni esthétique ;

  • en utilisant des enregistrements DNS de type SRV qui contiennent le numéro de port, évitant de l’indiquer dans l’URL. Il faut que le client supporte l’utilisation des enregistrements SRV. APT le fait pour accéder aux dépôts de paquets, mais je ne sais pas si les navigateurs le font.

Dans les deux cas l’utilisation d’un port non standard ne passe pas forcément par tous les pare-feu.

#9

Ce n’est pas le matériel qui fait le serveur … ce sont les services qu’il offre. Tu peux tout a fait être client et serveur à la fois, c’est même quasiment toujours le cas, client pour un service (NTP, DNS, …) serveur pour autre chose (FTP, SSH, MineCraft, …) ou client & serveur pour le même service.

Ce que je te recommande c’est de monter tout ton serveur sans httpS pour l’instant, tu verra pour ce raffinement par la suite. Et tu reviendra avec des questions précises. PH t’ayant fournis quelques pistes déjà.

Pour les conteneur tu as bien compris, 1 conteneur par services. Mais comme tes 2 sites vont avoir besoins du port http(80) et https(443) il va te falloir un autre service qui fera la redirection entre les 2. Mais pour simplifier tu peux mettre 1 conteneur pour tes 2 sites.
Mais déjà fait tout avec 1 site et on verra pour mettre en place le deuxième le moment venu.

#10

Je suis d’avis contraire. La sécurité et ses contraintes doivent être prises en compte dès le début. Il ne faut pas attendre la fin pour se rendre compte que les choix techniques qu’on a faits au début sont incompatibles avec les mesures de sécurité à appliquer.

Conteneurs, machines virtuelles ne changent rien au fait que tous les sites seront sur la même adresse IP publique.

#11

Merci Pascal et Mimoza,

@PascalHambourg : c’est bien ce que j’avais cru comprendre en me documentant mais tes explications sont très claires ; je vois que le conteneur n’est pas la solution pour ce que je veux faire.

Par contre, la solution traditionnelle qui consiste à ce que le serveur envoie le même certificat me semble être la solution la plus simple à mettre en œuvre pour moi ; d’autant que j’ai cru comprendre que let’s encrypt permet de déclarer plusieurs domaines.

Donc au final, je configure un seul vhost dans lequel je mets les alias des site1 et site2 y compris les sous domaines et le tour est joué ?! c’est bien ça ?

@Mimoza : En effet c’est pas le matériel qui fait le serveur, c’est un raccourci de langage car je ne suis pas informaticien. Mais j’ai bien compris le principe pour le coup :wink:

Pour les conteneurs je ne suis pas sur de m’y lancer car j’ai peur qu’une fois passé la mise en place, dans un an ou deux, s’il faut que j’intervienne dessus ce soit compliqué, que j’ai du mal à gérer / administrer et maintenir le system à jour. Je me réserve ça pour après afin de tester mais pas sur quelque chose en production.

Mon but est de mettre en place un serveur stable et sécurisé, c’est pour cela que je me pose autant de question en amont. Il faut peut être que je revois ma copie…

Merci encore d’éclairer mon chemin :sunny: , moi qui suit encore du coté obscure de la force !!! :crescent_moon:

#12

Bon ça me rassure, je suis la bonne procédure !

Allez je te tente de mettre en place “la solution traditionnelle : le serveur envoie toujours le même certificat qui contient en alias tous les sites HTTPS du serveur ;”

Je rouvrirai un autre billet en cas de problème.

Merci à tous :wink:

#13

Je ne connais pas grand-chose en configuration de serveur web apache et je n’ai jamais configuré de multisite en HTTPS, mais je pense que les sites doivent avoir des VirtualHost distincts comme en HTTP puisqu’ils ont des racines (DocumentRoot) différentes.
Les alias, c’est uniquement dans le certificat.

#14

Bon, je vois mieux ce que tu veux, c’est donc juste deux sites en https sur ton mutu perso.

Pour ça, oui, tu crées 1 config de “name virtualhost” dans /etc/apache/sites-available/ pour chacun de tes domaines bruts (sans www).
Doc, par exemple: https://wiki.apache.org/httpd/NameBasedSSLVHosts
Ensuite, quand la conf est prête a2ensite taconf.
Et ensuite tu vas modifier ta zone dns pour que chacun de tes ndd pointent vers ton ip serveur.

Tu auras ainsi accés à tes hosts par https://siteX.fr avec la sécurité des certifs que tu y auras configurée, c’est bon, la base fonctionnera.

Si en plus tu veux que tes visiteurs puissent se planter en tapant http sans le s ou en rajoutant www devant le nom de domaine, ou si tu as une partie que tu veux voir bien référencée par les moteurs de recherche, alors, tu fais un alias de www dans ta zone dns pour pointer vers ton ip, tu ajoutes 2 alias pour le www et tu étends l’ecoute de tes vhosts au port 80. En parallèle tu mets dans ton htaccess dà la racine une redirection 301 de proto http -> https, et une redirection www -> sans www pour systématiquement rediriger les formes canoniques (avec www et/ou en http) vers la forme canonique.
redirection de proto: https://stackoverflow.com/questions/8371/how-do-you-redirect-https-to-http
redirection www/sans, ou l’inverse: https://stackoverflow.com/questions/8371/how-do-you-redirect-https-to-http

#15

Non, ils partagent la même IP en revanche en front, il y a souvent un nGinx qui bascule sur le bon conteneur en fonction du domaine.

#16

Bonjour à tous,

Je reviens pour vous informer que j’ai résolu mon problème.

Je n’ai pas le temps aujourd’hui mais je reviendrai poster la solution mise en place en détail pour que cela puisse servir à d’autre.

En synthèse :
Diriger les DNS depuis mon provider vers mon IP publique
Configurer 1 fichier de conf dans lequel je précise spécifiquement sur quelle adresse IP et port le serveur doit écouter "listen xx.xx.xx.xx:443 et idem pour virtualHost, les clés SSL, puis mes différents vhost (site1, site2, site3, etc…).

Le tout en détail avec les fichiers de conf la prochaine fois :wink: et je fermerai ce billet.

C’est bien ce qui est décrit dans le lien de tu m’as communiquer, merci !

Bon Debian à tous !