Utiliser ses propres certificats avec ESXi 6.5

Divulgâchage : Comme beaucoup d’autres services, ESXI utilise une interface de configuration web qui utilise un certificat autosigné. Aujourd’hui, on va vous montrer comment modifier les certificats par défaut pour les remplacer par les vôtres. Il faudra activer SSH pour y téléverser les nouveaux certificats. Puis redémarrer la machine pour que ça soit pris en compte.

Plutôt que d’avoir une machine physique pour chacun de nos serveurs, on a préféré les virtualiser avec ESXi sur un Dell R620. C’est vrai que c’est une grosse machine, qui nécessite de l’énergie et une climatisation, mais avec pas moins de 15 serveurs virtuels, ça rentabilise notre impact carbone.

Comme d’autres services (i.e. Landscape et VitalPBX), ESXi utilise une interface de configuration Web qui, par défaut, n’est pas sécurisée car elle utilise un certificat autosigné.

Pete Linforth @ pixabay

On va donc, aujourd’hui, vous montrer comment modifier les certificats par défaut pour les remplacer par les vôtres, signés par votre propre CA et donc automatiquement validés par vos butineurs.

Téléverser son certificat

Comme vous êtes des pros de la création de certificats, je pars du principe que vous avez déjà vos deux fichiers disponibles (la clé dans esxi.pem, le certificat dans esxi.crt).

Bien que des menus parlent de sécurité et de certificats, l’interface web d’ESXi ne permet pas le genre de configuration qu’on va effectuer ici. Il va falloir mettre les mains dans le cambouis et modifier les fichiers directement en SSH.

Techniquement, comme il ne s’agit que de remplacer des fichiers, vous pourriez le faire en SCP via des outils graphiques (i.e. WinSCP).

Activer SSH

Par défaut, le serveur SSH n’est pas démarré. Vu le peu de cas où on en a besoin, c’est plutôt une bonne chose, mais aujourd’hui, on va en avoir besoin et on va donc le démarrer.

Pour ça, on va dans le menu Gérer (sur la gauche de l’interface) puis dans l’onglet Services. On clique sur la ligne correspondant à SSH puis sur le bouton démarrer.

Démarrer le serveur SSH

À noter que le démarrage n’est que temporaire. Lorsque le serveur redémarrera, le service ne sera pas automatiquement démarré, ce qui est exactement ce dont on a besoin aujourd’hui.

Sauvegarder les anciens

Comme toujours lorsqu’on veut rester prudent, il est de bon aloi de sauvegarder les anciens certificats. En cas de pépin, on pourra les réinstaller pour revenir dans la configuration initiale. Pour cela, on va simplement renommer les deux fichiers (clé et certificats) d’origine :

cd /etc/vmware/ssl
mv rui.crt orig.rui.crt
mv rui.key orig.rui.key

Personnellement, j’ai en fait renommé tout ce qui commençait par rui en orig.rui.

Remplacer par les nouveaux

Maintenant que la place est libre, vous pouvez ajouter vos fichier à la place des anciens. Ce ne sont pas les moyens qui manquent, en voici un utilisant SCP depuis l’ESXi si on considère les particularités suivantes :

cd /etc/vmware/ssl
scp vous@votremachine:/home/vous/esxi.crt rui.crt
scp vous@votremachine:/home/vous/esxi.pem rui.key

Personnellement, j’ai utilisé winscp, c’est bien plus pratique 😉 mais les captures d’écrans sont moins accessibles.

Et après ?

On pourrait chercher à ne redémarrer que l’interface web mais comme la documentation dit de redémarrer l’hôte, c’est ce que nous allons faire.

D’expérience, lorsque la documentation le mentionne, c’est qu’un risque d’instabilité existe si on redémarre uniquement le serveur web. Plutôt que de rembourser une dette technique, il est plus facile (pour les développeurs) de demander de redémarrer la machine (aux administrateurs).

On va donc dans le menu Hôte (à gauche) et on clique sur le bouton Redémarrer et on s’arme de patience car un serveur, ça prend du temps pour démarrer 😭.