vSphere 6.5 – Certificats approuvés 2 – L’ESX
Là encore, j’en avais assez des avertissement concernant le certificat autosigné à chaque fois que je me connectais aux ESXi via le navigateur. J’ai donc décidé de changer leurs certificats pour un certificat approuvé par une autorité de certification.
Il s’agit d’une suite à l’article vSphere 6.5 – Certificats approuvés 1 – Le vCenter avec lequel il a de grandes similitudes. Je vous invite donc à le lire au préalable car certains points ne sont pas détaillés à nouveau.
- Autorité de certification
- Génération de la demande de certificat
- Génération du certificat
- Import du certificat dans l’ESXi
- Plus d’erreur de certificat
Autorité de certification
J’ai réutilisé l’autorité de certification installée à l’occasion de la création du certificat du vCenter.
J’ai choisi de créer un certificat de type Web Server, en prenant mon template modifié pour un certificat valable 10 ans.
Génération de la demande de certificat
L’ESX ne disposant pas des binaires permettant de générer la demande de certificat, il va falloir passer par un outil tiers.
Personnellement j’ai utilisé OpenSSL, dans sa version 1.1.0f Light pour Windows disponible ici : https://slproweb.com/products/Win32OpenSSL.html
On peut aussi utiliser un serveur Linux, mais n’étant pas Linuxien dans l’âme, j’ai préféré ne pas raconter de bêtises.
L’installation est facile, il suffit de suivre l’assistant. Pour la configuration, le plus simple est de modifier le fichier openssl.cfg de OpenSSL, par défaut situé dans C:\OpenSSL-Win32\bin, pour ne garder que le nécessaire, et surtout pour le configurer de façon à n’avoir à répondre à aucune question.
Il faudra par conséquent le modifier pour l’adapter à chaque ESXi avant de générer la demande de certificat lui correspondant. En rouge les éléments à adapter
[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:shex01, IP:192.168.3.101, DNS:shex01.home.lab
[ req_distinguished_name ]
countryName = FR
stateOrProvinceName = France
localityName = Villefranche sur Saone
0.organizationName = Druard
organizationalUnitName = Home Lab
commonName = shex01.home.lab
Générer alors la requête de certificat à l’aide de la commande suivante :
openssl req -new -nodes -out rui.csr -keyout rui-tmp.key -config openssl.cfg
Le fichier rui.csr généré est la demande de certificat, et le fichier rui.key est la clef privée.
Cette dernière n’est pas au bon format pour l’ESXi, il faut la convertir :
openssl rsa -in rui-tmp.key -out rui.key
Le fichier rui-tmp.key n’est alors plus nécessaire.
Génération du certificat
Récupérer le fichier rui.csr, le copier sur le serveur autorité de certification, et passer la commande suivante :
certreq -submit -attrib "CertificateTemplate:WebServer" rui.csr
Dans cet exemple, c’est le template WebServer par défaut, avec une validité de 2 ans. Mais rien n’empêche d’en utiliser un autre.
Valider le choix de l’autorité racine. Ici il n’y en a qu’une.
Sauvegarder le certificat sous le nom rui.crt pour ne pas avoir à le renommer plus tard.
Le certificat est généré.
Le certificat généré est écrit en « clair », et peut s’ouvrir avec un éditeur de texte (ne pas utiliser Notepad, qui peut ajouter des caractères de contrôles, je lui préfère Notepad++).
Cependant le certificat n’est pas complet. Il ne contient que le certificat du serveur, et il faut lui ajouter les autorités de certification intermédiaires (s’il y en a) et racine, toujours en texte.
Voir dans l’article vSphere 6.5 – Certificats approuvés 1 – Le vCenter comment compléter le certificat avec celui des autorités intermédiaires et racine.
Import du certificat dans l’ESXi
A l’aide d’un outil de type WinSCP, copier les fichiers rui.crt et rui.key sur l’ESXi dans le répertoire /etc/vmware/ssl, à la place de ceux existant (vous pouvez les conserver en les renommant).
Il faut ensuite relancer les services de management.
Se connecter à la console de l’ESXi, ou bien se connecter en SSH et lancer la commande DCUI.
S’authentifier, aller dans Troubleshooting Options…
…puis Restart Management Agents
Valider le redémarrage par F11.
D’après un KB VMware, on peut redémarrer les agents avec ces deux commandes.
/etc/init.d/hostd restart /etc/init.d/vpxa restart
Cependant le redémarrage est nettement plus rapide que via la console ou DCUI, donc il est possible que ce ne soit pas tout à fait équivalent.
Se déconnecter de la console, ou faire [Ctrl]-[C] pour quitter DCUI.
Plus d’erreur de certificat
Avant :
Après :
