Synchroniser un certificat SSL avec reverse proxy et serveur IIS

Dans la continuation de mes articles sur Let’s Encrypt, voici un petit article permettant de résoudre un problème qui se pose lors de l’utilisation d’un reverse proxy.

Soit la situation suivante :

  • un serveur applicatif HTTPS utilisant le magasin de certificat de Windows, accédé en direct par les postes de travail internes
  • un reverse proxy HTTPS permettant d’accéder à ce serveur applicatif depuis Internet

On se retrouve alors avec potentiellement 2 serveurs HTTPS distinct donc deux certificats distincts. On pourrait les aligner, mais les certificats Let’s Encrypt ayant une durée de vie de 3 mois, la surcharge induite pour effectuer ce travail manuellement commence à peser, à moins d’automatiser cette opération avec un simple script.

Initialisation

La première fois est manuelle, et consiste à charger le certificat avec sa clé privée, donc obligatoirement sous forme PFX, depuis le reverse proxy vers le serveur applicatif. Cela va servir à charger la clé privée au niveau du serveur applicatif, opération qui ne sera pas faite ultérieurement, et donc simplifie la maintenance d’un point de vue de la sécurité. En effet il suffira par la suite de récupérer uniquement le certificat, donc la partie publique, ce qui se fait simplement en faisant une requête HTTPS au reverse proxy.

Récursion Répétition

Comme dit au premier paragraphe, la clé privée ne change pas, seul le certificat est renouvelé régulièrement auprès de Let’s Encrypt. Le script va donc :

  1. Effectuer une requête HTTPS au reverse proxy, en spécifiant l’hôte permettant de sélectionner le bon site (via l’extension SNI)
  2. La réponse, quelque soit le résultat HTTP (200, 404, 401…) contient le certificat, qu’on importe dans le magasin de certificat
  3. Le magasin de certificat contient la clé privée, ajouté précédemment, et un certificat sans clé privée mais dont la clé publique correspond à la clé privée. On va exécuter un programme qui va permettre de réassocier ces deux éléments
  4. La dernière étape consiste à reconfigurer IIS pour utiliser le nouveau certificat.

C’est l’objectif du script ci-dessous qui pourra être exécuté de manière périodique via le planificateur de tâches.

Enjoy !

Synchronisation asymétrique entre deux dossiers distants

J’ai écrit un (très) petit script qui me permet de synchroniser à sens unique deux dossiers distants.

Ce script s’exécute une fois par jour par cron. À chaque exécution, il va récupérer du dossier source tout ce qui aura été créé ou modifier depuis la dernière bonne exécution du script. Cette synchronisation asymétrique me permet de vider régulièrement le dossier local, qui est dans l’usage un tampon, sans que les éléments déplacés ne soient à nouveaux resynchronisés à partir du dossier distant.

 

Analyser l’impact d’une mise à jour ESXi

Lorsqu’on met à jour à la main un ESXi, il est possible d’analyser les paquets qui vont être installés, ceux qui vont être mis à jour, et ceux qui ne vont pas être touchés. On a alors une sortie qui ressemble à ça.

Comme on peut le voir, il est difficile d’avoir une vue claire permettant de savoir quel paquet va être mis à jour et en quelle version. J’ai à ces fins écris un petit script en PowerShell permettant d’améliorer la lisibilité de la sortie.

Il suffit de remplacer le contenu de $in  par ta sortie et $result  contiendra désormais la liste des packages impactés avec la version d’origine et la version de destination. Il est de même rapide de voir les paquets définitivement supprimés, les nouveaux et ceux qui ne seront pas impactés par la mise à jour.

Enjoy.

 

Description de l’authentification via NTLM en HTTP

Format Lien

Petit article que j’ai déniché expliquant comment fonctionne une authentification avec un site web utilisant le fournisseur NTLM. Note: je ne dis pas si c’est bien ou pas d’utiliser NTLM, juste de savoir comment ça marche.

Cela explique toutefois pourquoi je n’arrive pas à reverse-proxifier un site web qui utilise NTLM pour authentifier le client avec nginx.

NTLM Authentication Scheme for HTTP

rc-status ne voit pas crond

J’ai observé sur mon routeur Alpine que le daemon crond affichait tout le temps crashed.

Alors même qu’il était vivant vu que  pidof crond me renvoyait bien un PID.

Une analyse du script init.d revèle que le pid devrait se trouver dans le fichier  /var/run/crond.pid . Que nenni mon ami, ce fichier contient un PID inexistant, voilà pourquoi rc-status  affiche n’importe quoi !

C’est courant lorsque le script init.d récupère le PID du process qu’il lance, alors que ce dernier se fork encore une fois afin de pouvoir fonctionner en background.

On va résoudre ça vite fait. Examinons s’il est possible que crond crée le pid file, ou alors qu’il ne passe pas en arrière plan lui-même mais laisse faire start-stop-daemon.

Au vu des paramètres possibles, je dirais qu’on va tester crond en foreground. On édite donc /etc/conf.d/crond  pour préciser à crond de rester en background.

Et on relance le service avec rc-service crond restart . Et voilà c’est terminé ! … et là on remarque qu’il n’y a plus de crond du tout ! Et pas de messages d’erreur non plus.

Aux grand maux les grands remèdes, je sors l’artillerie lourde afin de comprendre ce qu’il s’est passé pour de vrai. Le passage intéressant est à la fin; il n’est pas nécessaire de lire toutes ces horreurs.