Ceci est un suivi de mon post précédent où nous configurons un simple serveur proxy inverse à l'aide de Nginx. Dans cet article, nous allons sécuriser la connexion entre le client et le serveur proxy inverse à l'aide de TLS gratuit (un.k.un certificat SSL) de LetsEncrypt. Je vous encourage à consulter le post susmentionné sur le proxy inverse pour les bases.

Conditions préalables

Un serveur avec une IP publique statique. C'est là que Nginx s'exécute.
Serveurs principaux avec le site Web prévu s'exécutant sur HTTP
Un nom de domaine enregistré. je vais utiliser ranvirslog.com comme nom de domaine principal et les deux sites Web sont sur des FQDN - ww1.ranvirslog.com et ww2ranvirslog.com

Installer

Les adresses IP ont donc changé depuis la dernière fois, depuis que je refais cette configuration. Voici les nouvelles IP et noms d'hôtes.

VM/Nom d'hôte	IP publique	IP privée	Rôle/Fonction
ReverseProxy	68.183.214.151	dix.135.127.136	Point de terminaison TLS et serveur proxy inverse
web1	N / A	dix.135.126.102	Hébergement ww1.ranvirslog.com site Web sur le port 80 HTTP
web2	N / A	dix.135.126.187	Hébergement seconde guerre mondiale.ranvirslog.com site Web sur le port 80 HTTP

Les enregistrements DNS sont configurés de telle sorte que les deux sites Web (différents sous-domaines) pointent vers la même IP publique statique. Il s'agit de l'adresse IP de notre proxy inverse Nginx :

Un enregistrement	Valeur
première guerre mondiale.ranvirslog.com	68.183.214.151
seconde guerre mondiale.ranvirslog.com	68.183.214.151

Pour faire fonctionner notre DNS inversé sur HTTP non crypté, nous avons créé deux fichiers dans /etc/conf.d/ nommé ww1.conf et seconde guerre mondiale.conf chacun avec la configuration suivante :

/etc/conf.j/ww1.conf

serveur
écouter 80 ;
écoutez [::]:80;
nom_serveur ww1.ranvirslog.com;
emplacement /
proxy_pass http://10.135.126.102/;
proxy_buffering désactivé ;
proxy_set_header X-Real-IP $remote_addr;

/etc/conf.j/ww2.conf

serveur
écouter 80 ;
écoutez [::]:80;
nom_serveur ww2.ranvirslog.com;
emplacement /
proxy_pass http://10.135.126.187/;
proxy_buffering désactivé ;
proxy_set_header X-Real-IP $remote_addr;

Le système d'exploitation que nous utilisons est Ubuntu 18.04 LTS et nous avons supprimé le fichier /etc/nginx/sites-enabled/default afin que Nginx puisse agir uniquement comme un DNS inversé en utilisant les configurations indiquées ci-dessus.

Objectif

Avec le DNS inversé (et les sites Web principaux) déjà opérationnels, notre objectif est d'installer un seul certificat TLS pour les deux FQDN (c'est ww1.ranvirslog.com et seconde guerre mondiale.ranvirslog.com) sur notre proxy inverse Nginx.

Le trafic entre n'importe quel client et le proxy inverse va être chiffré mais le trafic entre le proxy inverse et les serveurs backend n'est pas chiffré. Cependant, cela reste une option infiniment plus sécurisée que de ne pas avoir de HTTPS du tout. Pour les cas où le proxy inverse et les différents serveurs Web sont sur le même hôte, disons que si vous utilisez des conteneurs Docker pour héberger tous sur le même VPS, alors même ce trafic non chiffré est contenu sur un seul hôte.

Installation de Certbot

Certbot est un programme client qui s'exécutera sur notre serveur proxy inverse et négociera un certificat TLS avec LetsEncrypt. Cela prouvera à LetsEncrypt que le serveur a en fait le contrôle des FQDN sur lesquels il prétend avoir le contrôle. Nous ne nous soucierons pas de la façon dont Certbot le fait.

Traditionnellement, vous pouvez utiliser Certbot comme un logiciel autonome qui obtiendra simplement les certificats (qui ne sont en fait que de longues clés cryptographiques) et les enregistrera sur le serveur. Mais heureusement, pour la plupart des systèmes d'exploitation, il existe des plugins personnalisés pour Nginx, Apache et d'autres logiciels. Nous allons installer le plugin Certbot avec Nginx. Cela configurera automatiquement Nginx pour utiliser les clés nouvellement obtenues et éliminera les règles non sécurisées telles que l'écoute de HTTP sur le port 80.

Si vous utilisez des systèmes basés sur Debian, comme dans mon cas, j'utilise Ubuntu 18.04 LTS, alors l'installation est un jeu d'enfant.

$ sudo apt mise à jour
$ sudo apt install software-properties-common
$ sudo add-apt-repository univers
$ sudo add-apt-repository ppa:certbot/certbot
$ sudo apt mise à jour
$ sudo apt installer python-certbot-nginx

D'autres systèmes d'exploitation, votre RedHat, Gentoo, Fedora peuvent suivre les instructions officielles répertoriées ici.

Une fois que vous avez installé Certbot avec le plugin Nginx pour votre combinaison d'OS, nous pouvons nous mettre au travail.

Obtenir des certificats TLS

Pour obtenir le certificat TLS pour la première fois, exécutez la commande suivante :

$ sudo certbot --nginx

Cela va passer par une série de questions interactives, comme indiqué ci-dessous :

Entrer votre Email

Enregistrement du journal de débogage dans /var/log/letsencrypt/letsencrypt.Journal
Plugins sélectionnés : Authenticator nginx, Installer nginx
Entrez l'adresse e-mail (utilisée pour les avis de renouvellement urgent et de sécurité) (Entrez 'c' pour annuler) : [email protégé]

Accepter les CGU

Veuillez lire les conditions d'utilisation sur https://letsencrypt.org/documents/LE-SA-v1.2-novembre-15-2017.pdf. Vous devez accepter pour vous inscrire sur le serveur ACME à l'adresse https://acme-v02.api.permet de crypter.org/répertoire
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(A)accepter/(C)annuler : A

Bulletin optionnel

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Seriez-vous prêt à partager votre adresse e-mail avec l'Electronic Frontier Foundation, partenaire fondateur du projet Let's Encrypt et l'organisation à but non lucratif qui développe Certbot? Nous aimerions vous envoyer un e-mail sur notre travail de cryptage du Web, les actualités de l'EFF, les campagnes et les moyens de soutenir la liberté numérique.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Oui)oui/(N)o : Oui

Il détectera alors les noms de domaine sur votre serveur, et si vous souhaitez sélectionner tous les domaines appuyez simplement sur

Pour quels noms souhaitez-vous activer HTTPS?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 : première guerre mondiale.ranvirslog.com
2: seconde guerre mondiale.ranvirslog.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Sélectionnez les numéros appropriés séparés par des virgules et/ou des espaces, ou laissez la saisie vide pour sélectionner toutes les options affichées (Entrez « c » pour annuler) :

Rediriger tout vers TLS. J'ai choisi l'option 2, pour tout rediriger vers SSL mais votre cas d'utilisation peut différer. Pour les nouvelles installations backend, il est sûr de choisir l'option 2.

Veuillez choisir de rediriger ou non le trafic HTTP vers HTTPS, en supprimant l'accès HTTP.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

1 : Pas de redirection - N'apportez aucune autre modification à la configuration du serveur Web.
2 : Rediriger - Rediriger toutes les demandes vers un accès HTTPS sécurisé. Choisissez cette option pour les nouveaux sites ou si vous êtes sûr que votre site fonctionne sur HTTPS. Vous pouvez annuler cette modification en modifiant la configuration de votre serveur Web.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Sélectionnez le numéro approprié [1-2] puis [enter] (appuyez sur 'c' pour annuler): 2

Si tout s'est bien passé, il vous montrera ce message, juste pour vos noms de domaine à la place.

Toutes nos félicitations! Vous avez activé avec succès https://ww1.ranvirslog.com et https://ww2.ranvirslog.com Vous pouvez visiter les FQDN et remarquer que les sites Web ont maintenant le signe du cadenas suggérant que tout est crypté.

Regardez les fichiers de configuration

Si vous affichez les fichiers de configuration que nous avons créés précédemment, à savoir /etc/conf.j/ww1.conf et /etc/conf.j/ww2.conf, vous remarquerez que toutes les règles "Listen 80" ont disparu et que quelques nouvelles lignes ont été ajoutées pour indiquer au serveur que la communication doit être cryptée et l'emplacement des certificats et des clés pour effectuer ledit cryptage.

Je recommande fortement de parcourir les fichiers de configuration, car cela peut également vous apprendre à installer correctement les certificats et à écrire les fichiers de configuration.

Renouvellement de la certification

Les certificats LetsEncrypt typiques sont valides pendant 90 jours et avant leur expiration, vous devez les renouveler. Vous pouvez utiliser Certbot pour d'abord exécuter le renouvellement, en exécutant la commande :

$ sudo certbot renouveler --dry-run

Si l'opération réussit, le message suivant s'affichera :

Félicitations, tous les renouvellements ont réussi. Les certificats suivants ont été renouvelés :

/etc/letsencrypt/live/ww1.ranvirslog.com/chaîne complète.pem (succès)
** DRY RUN : simuler le « certbot renouveler » près de l'expiration du certificat
** (Les certificats de test ci-dessus n'ont pas été sauvegardés.)

Vous pouvez maintenant ajouter une tâche Cron qui tentera de se renouveler toutes les semaines environ. Certbot ne renouvellera pas les certificats à moins qu'ils ne soient vraiment dus pour cela, vous n'avez donc pas à vous inquiéter. La commande pour le renouvellement effectif est :

$ certbot renouveler

Ajoutez-le à la tâche cron de root en utilisant :

$ sudo crontab -e

Dans l'invite suivante, sélectionnez votre éditeur préféré (Choisissez Nano si vous n'êtes pas sûr) et ajoutez les lignes suivantes à la fin du fichier maintenant ouvert :

…
# Par exemple, vous pouvez exécuter une sauvegarde de tous vos comptes d'utilisateurs
# à 5h.m chaque semaine avec :
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /accueil/
#
# Pour plus d'informations, consultez les pages de manuel de crontab(5) et cron(8)
#
# m h dom mon dow commande
* 2 * * 2 renouvellement du certificat

Cela exécutera la commande de renouvellement de certbot à 2 heures du matin à n'importe quelle minute aléatoire, le deuxième jour de chaque semaine.

Conclusion

Si vous êtes nouveau sur les certificats TLS, expérimenter des choses comme HSTS peut être risqué. Puisque ces changements sont irréversibles. Cependant, si vous voulez descendre dans le terrier de la sécurité, je peux fortement recommander le blog de Troy Hunt, qui est l'une des principales inspirations de cet article.

Proxy inversé Nginx avec HTTPS via LetsEncrypt