Mot-clé - pound

Fil des billets

mercredi 19 octobre 2016

Let's Encrypt, comment l'usage d'un reverse proxy permet l'obtention de certificats sans se soucier nullement de la nature du service sous-jacent, cas pratique avec Pound et Apache

Quand on utilise un reverse proxy, il est possible de grandement simplifier l'usage de Let's Encrypt pour protéger tous ses accès avec HTTPS.

Méthodologie

Pour mémoire, afin de vérifier la bonne possession d'un domaine abc.tld, Let's Encrypt appelle l'adresse 'abc.tld/.well-known/acme-challenge/X' où X correspond à un nom de fichier unique que le client Let's Encrypt (par exemple certbot) aura créé lors du challenge ACME. Si le test réussit, c'est que l'utilisateur qui revendique le domaine en a pleinement la possession puisqu'il est capable de créer et rendre visible un fichier à sa racine ; le certificat est alors accordé et créé.

Dès lors : créons une règle sur le reverse proxy qui redirige toutes les requêtes de l'ACME challenge vers un seul emplacement dans lequel le client Let's Encrypt écrira !

En pratique avec Pound comme reverse proxy

Ajoutons un paragraphe en tête de la configuration de Pound :

        Service
                URL "/.well-known/acme-challenge/.*"
                BackEnd
                        Address 1.2.3.4
                        Port 8000
                End
        End

Désormais, toute requête de type ACME challenge est envoyé vers le serveur 1.2.3.4 sur le port 8000.

Imaginons que ce serveur soit un Apache. Paramétrons-le comme suit :

  • dans /etc/apache2/ports.conf, on ajoute une ligne Listen 8000
  • dans /etc/apache2/sites-available/letsencrypt.conf, on ajoute ceci :
<VirtualHost *:8000>
        DocumentRoot /var/www/letsencrypt
        <Directory /var/www/letsencrypt/>
                Options FollowSymLinks MultiViews
                AllowOverride All
		Require all granted
        </Directory>
</VirtualHost>
  • on active le site par a2ensite letsencrypt.conf
  • on redémarre Apache par service apache2 restart

Dès lors, tout appel à

certbot certonly --renew-by-default -a webroot --webroot-path /var/www/letsencrypt/ -d mondomaine.tld

devra aboutir à la génération du certificat souhaité, quelque soit le service sous-jacent !

En pratique avec un autre reverse proxy ?

La même stratégie est possible ! Seule la configuration du reverse proxy changera. On pourra également utiliser tout autre serveur web (même le micro-serveur web fourni dans python) pour servir les fichiers du ACME challenge !

Grafana & InfluxDB en HTTPS avec Let's Encrypt

Grafana et InfluxDB forment une jolie paire quand il s'agit de stocker et d'analyser des flux de données. J'ai donc voulu en sécuriser l'accès pour mes utilisateurs en permettant une connexion en HTTPS grâce aux certificats de Let's Encrypt.

Méthodologie

Pour Grafana comme InfluxDB, je n'ai pas réussi à faire accepter un dossier .well-known aux serveurs web empaquetés avec chacun des outils. J'ai donc fait intervenir le reverse proxy placé devant Grafana et InfluxDB.

Sommairement:

  1. toute requête de la forme http://url.de.grafana/.well-known/... ou http://url.de.influxdb/.well-known/... est renvoyée vers un hôte virtuel d'un serveur Apache
  2. toute autre requête est envoyée comme il se doit au serveur Grafana ou au serveur InfluxDB

Ainsi, quand Let's Encrypt effectue le test de possession du domaine, il trouve aux adresses http://url.de.grafana/.well-known/... ou http://url.de.influxdb/.well-known/... le fichier qu'il recherche et accepte alors la génération des certificats.

En pratique

La pratique dépend du reverse proxy. Dans mon cas, le reverse proxy est Pound. Dès lors on ajoute à la configuration de Pound le paragraphe suivant (avant les autres pour capturer la requête avant envoi vers un autre service) :

        Service
                HeadRequire "Host: .*(url.de.influxdb).*"
                URL "/.well-known/acme-challenge/.*"
                BackEnd
                        Address 1.2.3.4
                        Port    8000
                End
        End

avec 1.2.3.4 un serveur (par exemple Apache) qui répond sur le port 8000 en retournant le contenu de /var/www/pour-letsencrypt.

Il suffit alors d'appeler

certbot certonly --renew-by-default -a webroot --webroot-path /var/www/pour-letsencrypt/ -d url.de.influxdb

pour générer le certificat valide que l'on pourra ensuite utiliser pour protéger l'accès à InfluxDB ou Grafana !

dimanche 20 mars 2016

ownCloud/Nextcloud, Pound et MKCALENDAR

A compter de la version 9.0, ownCloud/Nextcloud utilise le mot clé MKCALENDAR dans l'application Calendrier. Ce mot clé est utilisé pour provoquer la création d'un nouveau calendrier/nouvel agenda sur l'interface en ligne. Or, ce mot HTTP n'est pas reconnu dans la version de Pound, le load balancer, disponible sur Debian Jessie.

Première approche de solution

On peut noter que ce point a été traité par les développeurs de Debian ici. Ainsi, la version 2.6-6.1, disponible sur Debian Testing/Unstable accepte le mot clé MKCALENDAR.

Il est donc possible d'installer le paquet de Testing/Unstable (à condition d'avoir bien paramétré /etc/apt/sources.list et /etc/apt/preferences) à l'aide de la commande :

apt-get -t unstable install pound

Seconde approche de solution

La version de Pound utilisée dans Jessie et Sid est pour l'instant la version 2.6 qui souffre de certaines faiblesses (même si les mainteneurs ont fait un travail formidable pour prendre en compte les bugs critiques et améliorer la sécurité). Dès lors, certains préféreront peut-être utiliser la version 2.7 stable disponible mais non proposée par Debian pour le moment.

Il faudra alors compiler manuellement Pound (ce qui n'est pas très compliqué). Mais stupeur, la version 2.7 de Pound ne supporte pas MKCALENDAR. Il faut donc patcher le fichier config.h pour inclure MKCALENDAR ! Là encore ce n'est pas bien compliqué.

Bonne compilation de Pound !