Let’s Encrypt… sur ESXi

closeCet article a été publié il y a 4 ans 11 mois 22 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Hoplà, j’en avais marre d’avoir des certifs auto-signés sur mes ESXi. Surtout depuis la mise en place de HSTS sur des domaines entiers (je vais tâcher de pondre un rapide article sur HSTS prochainement), les navigateurs hurlaient en voyant l’interface web (en https, donc) de ESXi présenter des certifs auto-signés. Il fallait désactiver HSTS sur ces sites au niveau du serveur web ou le court-circuiter pour ces sites au niveau du navigateur ou trouver une autre solution…

J’utilise principalement des ESXi 6.5. A voir pour des versions différentes si ce que je raconte ci-dessous reste vrai. Vous me direz.

Ce qu’on trouve comme informations sur le web

On arrive facilement à glaner les informations suivantes :

  • Les certifs auto-signés sont dans /etc/vmware/ssl/, fichiers rui.key et rui.crt
  • Les permissions de la clef privée (le .key) sont en 400 (read-only root), il faudra changer momentanément
  • Pour prendre en compte le changements, la plupart des gens recommandent de relancer l’hôte (pratique pour une prod pour un si petit changement) ou de relancer *tous* les services (!) grâce à /sbin/services.sh restart. Je trouve ça archi-bourrin. Je propose mieux ci-dessous

Reste à générer un certif letsencrypt et remplacer. Sauf que.

Le principal problème

J’utilise le script dehydrated comme outil pour mettre à jour mes certifs Let’sEncrypt. Que ce soit cet outil ou un autre, le problème est que pour réussir un « challenge » prouvant votre propriété d’un nom de domaine, il faut pouvoir le lancer sur une machine sur laquelle on a un peu la main. Pas un ESXi car installer un équivalent de script comme ça sur ESXi (assez bridé) me semble bien impossible.

Solution proposée

En supposant que l’ESXi sur lequel on veut un certif ait comme nom de domaine « monesxi.mondomaine.fr ». Grâce aux certifs wildcard de Let’s Encrypt, on va pouvoir générer un certif valable « *.mondomaine.fr » depuis la machine mondomaine.fr, disons un Linux normal où on a la main et où on peut faire tourner régulièrement un script interagissant avec let’s encrypt.
Il suffit alors de recopier ce certif wildcard, par SSH, sur l’ESXi (en prenant soin de sauvegarder ceux auto-signés des fois qu’ils resservent un jour…).
Tout ça va pouvoir se scripter assez aisément à grand coup de SSH pour recopier le résultat sur l’ESXi : regénération tous les 3 mois, copie des nouveaux certifs et relance du service web de l’ESXi.

Je passe sur la manière de scripter la génération d’un wildcard letsencrypt par dehydrated. J’utilise le « challenge DNS » avec un hook qui va bien pour interfacer dehydrated et l’hébergeur de mon DNS, un classique OVH dans le cas qui m’intéresse. C’est décrit dans un précédent article ici.

Reste à relancer le service web de l’ESXi pour prendre en compte la modification. Au lieu de rebooter ou relancer tous les services (long et dangereux), en cherchant un peu on trouve un script init.d appelé /etc/init.d/rhttpproxy. En tentant sa chance avec un bon vieux /etc/init.d/rhttpproxy restart, et bien hop, un reload de la page https du serveur et ça marche. Le certif présenté est celui de Let’sEcnrypt.

Voilà, ça fait plus joli dans la barre d’adresse. Et ça évite une surprise si HSTS est un peu trop violent avec votre navigateur (j’en parle même pas si vous avez fait un « preload » sur hstspreload.org et que vous constatez après coup que ESXi n’ont pas de certifs valables. Oops, j’ai failli me faire avoir).

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

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