Passage du HTTP au HTTPS (apache2) et modification du LVS

Cet article est dans la continuité de l’article sur le LVS et KeepAlived (que vous pouvez retrouver ici), après avoir mis en place KeepAlived on va faire en sorte que nôtre site web soit sécurisé grâce à un certificat SSL auto signé.

Comme on a deux serveurs web, on va commencer par en passer un en HTTPS puis on passera le second, ensuite on pourra faire la modification du cluster web.

I°) Passage en HTTPS

Pour commencer on doit activer le mode SSL d’apache2.

On va également activer le mode rewrite qui nous permettra de rediriger tous les demandes d’HTTP vers HTTPS.

Ensuite on va créer nos certificats, pour ça on commence par créer un dossier dans lequel on va mettre nos certificats.

On entre dans notre dossier et on crée notre certificat et on le signe.

Regardons plus en détails ce que fais cette commande. On utilise l’outil OpenSSL, l’option req nous permet de signer notre certificat, notre certificat est un certificat X.509 (-x509) qui n’est pas sécurisé via une passphrase (-nodes). Notre certificat est valide pendant un an (-days 365), on précise que c’est une nouvelle clé RSA de 2048bits (-newkey rsa:2048). Et on précise le nom de la clé (-keyout) et le nom du certificat (-out).

Quand on lance la commande, openssl nous demande des informations sur le certificat.

Maintenant que l’on dispose de notre certificat et de notre mode SSL, on modifie le fichier /etc/apach2/sites-availables/000-default.conf (c’est le site web que l’on veut passer en https). On importe le contenue du fichier /etc/apache2/sites-availables/default-ssl.conf et l’on va le modifier comme sur l’image ci-dessous :

On a modifié l’option ServerName pour y indiquer le nom de notre serveur web. On modifie l’option DocumentRoot si les fichiers de notre site web ne sont pas dans le dossier par défaut. Il ne faut surtout pas oublier d’indiquer le chemin vers notre certificat (SSLCertificateFile) et vers notre clé (SSLCertificateKeyFile).

Dans la définition de notre virtual host HTTP on ajoute l’option redirect permanent pour rediriger toutes les requêtes HTTP vers le HTTPS.

On oublie pas de redémarrer le service apache2 (/etc/init.d/apache2 restart) pour prendre en compte les modifications et l’activation des modes, puis on test.

On fait la même chose sur le deuxième serveur.

Remarque : Comme on a auto signé le certificat, les navigateurs web ne reconnaissent pas l’autorité de certification on a donc une page de ce type qui s’affiche :

Pour la passer il faut ajouter une exception de sécurité.

II°) Modification de KeepAlived

Remarque : Il faut faire ces modifications sur les deux serveurs (le BACKUP et le MASTER)

On va modifier les serveur KeepAlived (modification du fichier /etc/keepalived/keepalived.conf), dans la partie définissant nos différentes instances nous ajoutons le cluster HTTPS (nommée ssl_web).

A la fin du fichier de configuration on ajoute la définition de notre instance ssl_web, la définition de l’instance sur le serveur BACKUP :

Remarque : Sur le serveur MASTER seul l’option state et la priority sont différentes.

Remarque : On avait déjà une instance (l’instance HTTP) c’est pourquoi il faut changer le router id. L’option virtual_router_id permet de mettre un identifiant arbitraire à chaque instance.

Il faut écrire les informations concernant l’adresse IP virtuelle et les serveurs physiques, comme on avait fait dans l’article sur keepalived à la différence que l’on détermine les adresses sur le port 443 et non 80.

On vérifie notre configuration grâce au log du serveur, on ouvre notre navigateur web préféré et on va sur notre site web via l’adresse virtuelle.

III°) Modification du pare-feu

Notre pare-feu est un IPCOP, pour voir comment créer des règles, je vous renvoies vers mon article sur IPCOP.

Notre pare-feu filtre les règles entre nos LAN et notre DMZ, comme les serveurs web (et keepalived) sont dans la DMZ il faut ajouter une règle de filtrage pour autoriser les utilisateurs du LAN à atteindre nos serveurs web.

Ensuite on ouvre le port 443 (port forwarding) pour pouvoir atteindre notre site web depuis l’extérieur.

Nous avons maintenant un site web en Load Balancing sécurisé avec SSL.

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.