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. VitalPBX), ESXi utilise une interface de configuration Web qui, par défaut, n’est pas sécurisée car elle utilise un certificat autosigné.
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 .
À 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 :
- vous est votre nom de compte sur votre machine,
- votremachine est le nom d’hôte ou l’adresse IP de votre machine,
/home/vous/
est votre répertoire personnel sur votre machine et contient les certificats.
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 et on s’arme de patience car un serveur, ça prend du temps pour démarrer 😭.