Les divers flux de communication entre les différents éléments d'une infrastructure vSphere (par exemple le dialogue entre le serveur ESX(i) et le serveur vCenter) transitent dans un canal sécurisé avec SSL. Par défaut les certificats SSL qui permettent le chiffrement / déchiffrement du trafic réseau crypté, et qui sont générés automatiquement lors de l'installation de ESX(i) ou de vCenter sont auto-signés et sont des clés de 512 bits. Il est légitime pour des raisons de sécurité (et en outre recommandé par VMware), de souhaiter remplacer les certificats d'origines par d'autres émis par une autorité de certification digne de confiance. Il est possible de se tourner vers une autorité de certification externe comme VeriSign, ou alors d'utiliser une autorité de certification interne à l'entreprise.
La documentation VMware à ce sujet est un peu floue et je vais donc décrire ici mon propre retour d'expérience avec l'utilisation d'une autorité de certification sous Windows 2008 R2.
Configurer l'autorité de certification
Je ne reviendrais pas ici sur la mise en place et la configuration initiale d'une autorité de certification racine de confiance sous Windows 2008 R2 car ce n'est pas le propos de mon article. Cependant j'ai créé un modèle de certificat (fonctionnalité disponible dans l'outil de gestion des certificats sous Windows 2008), ce qui m'a permis de simplifier le processus d'approbation de la demande de certificat.
Pour créer un modèle de certificat, rendez-vous dans Server Manager / Active Directory Certificate Services / Certificate Templates. Pour ne pas partir de zéro j'ai dupliqué puis modifié un modèle existant. J'ai choisi le modèle "RAS and IAS Server" qui se rapproche le plus de l'utilisation avec les serveurs ESX(i) et le serveur vCenter.
Il suffit de cliquer droit sur le modèle de certificat à dupliquer puis de choisir "Duplicate Template". Cette action créé un autre modèle de certificat qu'il est possible de nommer à sa convenance et dont il est possible de changer les différents paramètres.
Dans la fenêtre suivante, choisir " Windows Server 2003 Enterprise" et cliquer sur "OK".
Dans l'onglet général, donner un nom au modèle (ici "vSphere"), ainsi qu'une période de validité.
Dans l'onglet "Subject Name", choisir "Supply in the request", ainsi les diverses informations (comme le sujet par exemple) seront fournies dans la requête du nouveau certificat.
Dans l'onglet "Extensions" modifier l'extension "Key Usage". Dans les détails de "Key Usage" choisir "Digital signature", "Allow key exchange only with key encryption" et "Allow encryption of user data". Valider par "OK".
Dans l'onglet "Request Handling" choisir une valeur pour "Minimum key size" (VMware recommande d'utiliser la valeur 1024 bits pour la taille de la clé, utiliser 2048 bits comme dans l'exemple peut poser des problèmes de performances). Il est également possible de choisir si la clé privé peut être exportée ou non. Enfin dans la zone de sélection des fournisseurs (bouton "CSPs") choisir "Requests can use any CSP available on the subject's computer". Enfin cliquer sur "OK" pour valider.
Une fois que le nouveau modèle de certificat est créé, il est nécessaire de le publier afin qu'il soit possible de l'utiliser pour répondre aux requêtes de nouveaux certificats. Pour cela rendez-vous dans Server Manager / Active Directory Certificate Services / "Le nom de votre autorité de certification" / Certificate Templates. Cliquer droit dans la zone des certificats publiés et choisir "New / Certificate Template to Issue".
Dans la liste choisir le certificat qui a été créé à l'étape précédente. Cliquer sur "OK" pour valider.
Le modèle de certificat est prêt à être utilisé.
Changer le certificat du serveur vCenter
La première étape pour remplacer le certificat du serveur vCenter, consista à générer une requête de nouveau certificat qui sera communiquée au serveur autorité de certification. La création de la requête peut être effectuée de différente manière, j'ai choisi d'utiliser les outils openssl présents sur une de mes machines virtuelles exécutant un Linux (Debian 5).
Sur la machine Linux ==>
Commencer par éditer sous Linux le fichier "openssl.cnf" (faire éventuellement une copie pour l'utilisation suivante) en modifiant / vérifiant les lignes suivantes :
[ ca ]
default_ca = CA_default
[ CA_default ]
private_key = $dir/myroot.key
[ req ]
# (la valeur ci dessous doit correspondre au moins à ce qui a été indiqué pour le modèle de certificat dans l'autorité de certification)
default_bits = 2048
default_keyfile = rui.key
Lancer ensuite la commande suivante dans votre répertoire /home/username/ :
openssl req -new -nodes -out ma_requete.csr -config openssl.cnf
Il résulte de cette commande 2 fichiers :
-
La requête de certificat (ma_requete.csr)
-
La clé privée (rui.key) correspondante au certificat qui sera créé par l'autorité de certification
Copier le fichier ma_requete.csr sur le serveur autorité de certification.
Sur le serveur autorité de certification ==>
Dans une fenêtre "ligne de commande" exécuter la commande suivante :
certreq -submit -attrib "CertificateTemplate:vSphere" ma_requete.csr rui.crt
Cette commande soumet la requête de nouveau certificat au serveur autorité de certification en indiquant le modèle de certificat à utiliser (créé à la première étape). S'il n'y a pas d'erreurs, le serveur accepte la requête et créer le fichier rui.crt (le certificat clé publique). A ce stade il est possible de supprimer le fichier ma_requete.csr.
Copier le fichier rui.crt sur la machine Linux (au même endroit que le fichier rui.key).
Sur la machine Linux ==>
Lancer la commande suivante :
openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:testpassword -out rui.pfx
Cela permet de créer le fichier rui.pfx qui est une "fusion" de la clé publique et de la clé privée qui composent le certificat. Noter bien que le paramètre "pass" doit obligatoirement avoir la valeur "testpassword" (ce n'est pas un exemple comme la documentation semble le sous entendre mais un prérequis).
Sur le serveur vCenter ==>
Commencer par sauvegarder les 3 fichiers du certificat actuel qui sont placés par défaut dans le répertoire suivant :
-
Pour Windows 2003 ==> C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL\
-
Pour Windows 2008 ==> C:\Users\All Users\Application Data\VMware\VMware VirtualCenter\SSL\
Arrêter le service vCenter avec la commande suivante :
net stop vpxd
Réinitialiser le mot de passe de la base de données de vCenter en exécutant la commande suivante à partir du répertoire racine de vCenter (par défaut "C:\Program Files\VMware\Infrastructure\VirtualCenter Server") :
vpxd -p
Copier et remplacer sur le serveur vCenter (voir plus haut pour le répertoire) les 3 fichiers rui.crt, rui.key et rui.pfx précédemment créés.
Démarrer le service vCenter avec la commande suivante :
net start vpxd
La communication entre le client vSphere et le serveur vCenter utilisera maintenant le certificat signé par l'autorité de certification. A ce stade il est recommandé de redémarrer le serveur vCenter et de tester une à une les fonctionnalités utilisées habituellement, et notamment celles qui font recours aux WebServices Tomcat comme les onglets "Storage View" ou encore "Hardware Status" sur un serveur hôte dans la vue "Hosts and Clusters".
Changer le certificat des serveurs ESX(i)
Il est également légitime de vouloir changer les certificats auto-signés des serveurs ESX(i). La procédure de création du certificat est similaire à celle employée pour le serveur vCenter.
Sur la machine Linux ==>
Utiliser la même machine Linux avec le même fichier openssl.cnf que précédemment.
Lancer la commande de génération de requête de certificat dans votre répertoire /home/username/ :
openssl req -new -nodes -out ma_requete.csr -config openssl.cnf
Copier le fichier ma_requete.csr sur le serveur autorité de certification.
Copier le fichier rui.key sur le serveur ESX(i) dans le répertoire /etc/vmware/ssl/ (effectuer auparavant une sauvegarde des fichiers rui.crt et rui.key).
Sur le serveur autorité de certification ==>
Lancer la commande de soumission de la requête de nouveau certificat :
certreq -submit -attrib "CertificateTemplate:vSphere" ma_requete.csr rui.crt
Copier le fichier rui.crt sur le serveur ESX(i) dans le répertoire /etc/vmware/ssl/.
Sur le serveur ESX(i) ==>
Les deux fichiers rui.key et rui.crt ont été remplacés à l'étape précédente. Cependant, comme l'autorité de certification créée un fichier crt dont l'entête comporte des caractères cachés que ne sait pas interpréter vCenter, il est nécessaire d'effectuer la manipulation décrite dans la base de connaissance VMware ici http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1004875. Cette manipulation consiste à recréer le fichier rui.crt de manière à la rendre lisible par vCenter.
Une fois le fichier rui.crt modifié, redémarrer le serveur ESX(i).
Sur l'infrastructure vSphere ==>
Après le changement de certificat, il est nécessaire de reconnecter chaque serveur hôte ESX(i) au serveur vCenter en indiquant à nouveau le compte root (ou équivalent)
Conlusion
La procédure de remplacement des certificats d'origines sur les serveurs ESX(i) et vCenter est relativement simple mais reste cependant fastidieuse. Il est nécessaire de se montrer rigoureux et de valider le fonctionnement de l'infrastructure vSphere après chaque grande étape (une fois après le remplacement du certificat sur le serveur vCenter et une fois après le remplacement sur les serveurs ESX(i). Il est également nécessaire d'être très attentif aux effets de bords sur les autres logiciels qui se connectent à vCenter (Site Recovery Manager, Update Manager, Orchestrator, etc.), et sur les fonctionnalités annexes de vCenter. En effet, certaines d'entre elles comme "Customization Specifications Manager" cryptent (et décryptent) certaines informations à l'aide du certificat. C'est le cas du mot de passe administrateur qu'il est possible d'indiquer dans un profile "Guest Customization". Si le certificat de vCenter a été modifié après la création d'un profile (avec mot de passe administrateur), ce dernier ne pourra plus être appliqué au déploiement d'un "template". Il sera alors nécessaire de modifier (et enregistrer) le profile en indiquant à nouveau le mot de passe administrateur.
