GuiGui's Show

Pour activer la prise en charge de HTTPS dans un uwsgi (un serveur d'applications qui cause WSGI, un protocole pour transférer des requêtes HTTP à des applications web Python, plus d'infos ici) installé avec pip sur un système GNU/Linux Debian Stretch :

• Installer les entêtes de la bibliothèque OpenSSL sudo apt-get install libssl-dev ;
  
  

• Réinstaller et recompiler uwsgi (oui, c'est voulu de l'installer au niveau du système et non dans un environnement, c'est la doc' du logiciel final, celui qui se repose sur uwsgi, qui le demande) : sudo pip3 install uwsgi --ignore-installed --no-cache-dir (--no-cache-dir permet de ne pas utiliser le wheel - lire ci-dessous - construit lors d'un précédent pip install, distribution python dans laquelle HTTPS n'est pas activé par absence des entêtes de la libssl) ;

• Changer la configuration de uwsgi en ajoutant les lignes suivantes. Le « =0 » désigne la première socket créée (dans mon cas, celle partagée, celle qui écoute sur le port tcp/8443 de l'IP 127.0.0.1), « =1 » la deuxième, etc. Apparemment, les sockets WSGI (non-HTTP) crées avec la directive de configuration « socket » n'entrent pas dans ce compte.

  shared-socket = 127.0.0.1:8443
  https = =0,/chemin/vers/le/certificat/x509.crt,/chemin/vers/la/clé/privée_associee.key

• On remplace « http:// » par « https:// » dans la configuration de notre proxy Apache httpd frontal. Exemple :

  SSLProxyEngine on
  ProxyPass "/" "https://127.0.0.1:8443/"
  ProxyPassReverse "/" "https://127.0.0.1:8443/"

Le même certificat x509 est utilisé par le serveur proxy Apache httpd et par uwsgi. Je m'étonnais de ne pas avoir eu à désactiver la vérification du nom d'hôte dans le certificat x509 dans le cadre de la communication entre Apache httpd et uwsgi (« SSLProxyCheckPeerName off »). Mais la doc' d'Apache httpd est limpide à ce sujet : ce n'est pas l'URI qui est donnée en argument de « ProxyPass » qui est comparée avec les noms présents dans le certificat x509 présenté par uwsgi, mais l'URI demandée par le client web final au serveur Apache httpd.

Ne me demandez pas pourquoi je n'utilise pas la fonctionnalité proxy uwsgi d'Apache httpd : je suis intervenu sur une architecture déjà conçue et mise en œuvre uniquement pour activer HTTPS entre le proxy Apache httpd et uwsgi. Dit autrement : le proxy http était activé avant que j'arrive.

Python, pip, les distributions et les extensions C/C++

J'ai appris que pip permet de distribuer et d'installer des distributions sources (fichiers et métadonnées, nécessitant une construction avant installation), des distributions compilées (un paquet qui contient les fichiers sources Python ou du bytecode et les métadonnées qu'il suffit de déplacer aux bons endroits pour que l'installation soit terminée) et des distributions binaires (une distribution compilée mais avec du code Python lié à des librairies C/C++). Par défaut, pip récupère, dans le dépôt, une distribution compilée si elle existe.

uwsgi est une distribution binaire : du code Python est lié à une librairie C. pip télécharge une distribution source (car il y a uniquement cela dans le dépôt), la construit, puis construit une distribution compilée (un wheel) avant d'installer ce wheel. Le code C est re-compilé dès que le fichier wheel est absent (ou que le paramètre no-cache-dir est utilisé ;) ). C'est donc ça qui permet d'activer la prise en charge de HTTPS dans uwsgi en installant les entêtes C de la librairie OpenSSL puis en générant à nouveau le wheel Python, car cela recompile le code C de uwsgi en sous-main. Tout s'explique.