vCSA (vCenter Server Appliance) – Partie 4 – Mise en place de certificats personnalisés

Dans la partie précédente, nous avons terminé de mettre en place notre appliance. Mais si nous voulons un résultat vraiment impeccable, il nous reste une “petite” chose à faire : remplacer les certificats auto-signés de l’appliance par des certificats de confiance : les nôtres !

Disons-le franchement : historiquement, le remplacement des certificats pour l’environnement VMware a toujours été une grosse galère. Depuis le travail exceptionnel de Michael Webster et Derek Seaman, les choses se sont nettement améliorées. Nous avons d’abord pu avoir des procédures claires pour remplacer les certificats auto-signés par des certificats signés en interne, puis Derek est allé encore un cran plus loin en proposant un script powershell permettant d’automatiser et de simplifier une partie du travail.

En parallèle, VMware a grandement amélioré sa documentation et depuis les toutes dernières versions, propose un outil complémentaire à celui cité plus haut (… mais qui ne supporte pas encore la vCSA).

C’est donc mieux qu’avant, mais toujours pas vraiment bien intégré. Reste que la procédure, aussi longue soit-elle, ne présente pas de grande difficulté ; nous allons donc essayer d’en profiter pour installer de beaux certificats tous neufs sur notre belle appliance tout neuve !

Préparation de l’environnement

Dans cette phase préparatoire, nous allons configurer notre autorité de certification pour émettre des certificats adaptés, puis nous mettrons en place l’outil de génération de certificats.

Création d’un modèle de certificat

Dans ce guide nos certificats vont être délivrés par une autorité de certification Microsoft interne. Or les modèles de certificats fournis par défaut ne conviennent pas aux besoins de notre appliance. Nous allons donc commencer par nous connecter au serveur de certificats (racine ou intermédiaire, selon votre infrastructure) pour créer un modèle adapté. Nous sommes ici en Windows 2008 R2 (anglais), mais les étapes seront les mêmes en 2012 ou 2012 R2. Nous suivons les instructions de la kb VMware, en ajoutant quelques trucs et astuces 🙂 !

Démarrez la console de gestion des modèles avec la commande certtmpl.msc. Dans la liste des modèles disponibles, trouvez le modèle Web Server, faites un clic droit dessus et choisissez Duplicate Template (dupliquer le modèle).Attention : laissez votre modèle en version 2003, en 2008 cela ne marchera pas (en particulier, vous ne verrez pas le modèle de certificat lors de la demande en ligne).C’est maintenant le moment de configurer le nouveau certificat. Donnez-lui un nom sans espace (vous pourriez en mettre dans le nom affiché (display name) mais il n’en faut pas dans le nom du modèle (template name), alors autant que cela soit cohérent !). Je vous recommande aussi d’augmenter la durée de vie du certificat. C’est déjà long de le faire une fois, alors le refaire tous les ans…Allez ensuite dans l’onglet Extensions, sélectionnez Key usage (utilisation de la clé) puis cliquez sur Edit… (modifier).Sélectionnez Signature is proof of origin (nonrepudiation) et Allow encryption of user data. Puis faites OK.

Nous sélectionnons maintenant Application Policies et faisons Edit…, puis nous cliquons sur Add… et enfin nous ajoutons Client authentication.

De gauche à droite…

Petite vérification au passage, dans l’onglet Subject Name, assurez-vous que Supply in the request soit coché !Enfin, placez-vous dans l’onglet Security et assurez-vous que le (les) compte(s) que vous allez utiliser pour générer les certificats disposent au moins des droits Read et Enroll. Puis vous pouvez valider votre nouveau modèle de certificat !Il faut maintenant publier ce nouveau modèle. Pour cela ouvrez la console de gestion de l’autorité de certification (via les outils d’administration ou via certsrv.msc), développez votre autorité de certification, puis clic droit sur Certificate Templates, New, Certificate Template to Issue.Enfin, sélectionnez votre nouveau modèle dans la liste des certificats et faites OK.Voilà ! Votre autorité de certification est maintenant prête à délivrer des certificats adaptés à notre appliance vCenter (mais pas seulement : ce modèle pourra également être utilisé pour des hôtes ESXi, Update Manager, vCOps…).

Préparons maintenant l’outil de génération des certificats.

Configuration de l’outil de génération des certificats

Ici encore nous allons nous appuyer sur le travail de Derek Seaman et utiliser son outil de génération de certificats. Commencez par aller le télécharger ici. Enregistrez-le sur une machine d’administration Windows (avec au minimum powershel v3) dans un dossier de votre choix. Ici nous utiliserons le dossier d:\Certificates.

Editez le script avec l’outil de votre choix. Je vous recommande Powergui mais si vous n’êtes pas un scripteur régulier l’outil par défaut de Windows (Powershell ISE) fera très bien l’affaire.

Modifiez les chemins de certificat vers votre dossier créé plus tôt. Le dossier openssldir ne doit pas exister, ainsi la dernière version sera automatiquement téléchargée et installée. Puis éditez correctement les paramètres d’emplacement, car ils seront utilisés dans vos certificats.

Maintenant nous paramétrons notre autorité de certification dans le script :$rootCA et $subCA sont vos autorités de certification racine et intermédiaire. Elles doivent être en ligne et supporter l’enrôlement web. Mettez le nom du server (FQDN). Normalement les sites d’enrôlement sont en https ; si ce n’est pas votre cas, modifiez $CADownload et remplacez https par http. Puis, pour $ISSUING_CA, mettez le nom de l’autorité de certification qui va délivrer les certificats (sous la forme nomDuServeur\nomDel’Autorité). Vous trouverez le nom de l’autorité dans la console de gestion des certificats que vous avez utilisé plus haut. Enfin, indiquez le nom de votre template ; ici nous avions mis VMware-Certificate. Vous pouvez sauvegarder le script.

Quelques remarques complémentaires à propos de cette configuration :

Si vous n’avez qu’une autorité racine, l’exemple ci-dessus correspond bien.
Si vous avez une racine et une intermédiaire, renseignez également $subCA. $ISSUING_CA sera probablement aussi modifié pour pointer sur l’intermédiare.
Si vous avez une racine et deux intermédiaires… Dommage, ce n’est pas géré par le script pour le moment (mais vous pouvez suivre la procédure manuelle ici).

Dernière étape préparatoire : le téléchargement de la chaîne de certificats de l’autorité de certification. Pour cela, accédez à https://ma-ca.mon-domaine/certsrv (si ça ne marche pas, essayez en http ; si ça ne marche pas, la suite ne marchera pas non plus, arrêtez-vous ici et résolvez ce problème !) et choisissez de télécharger la chaîne de certificats.Puis sélectionner l’encodage Base64, et téléchargez la chaîne de certificats.Enregistrez ce fichier en tant que cachain.p7b dans le même dossier que là où vous stockerez les certificats (chez nous, d:\Certificates).

Nous y sommes !

Génération des certificats

L’appliance n’a pas besoin d’autant de certificats que le vCenter sous Windows : il ne lui en faut que (?!) quatre :

un pour le service vCenter Server (utilisé aussi pour le SSO, le web client et le composant VAMI (moteur de gestion des virtual appliances)).
un pour le vCenter Inventory Service.
un pour le VMware Log Browser.
un pour VMware AutoDeploy (il n’est pas nécessaire de traiter ce composant si vous n’allez pas utiliser AutoDeploy, mais si déjà on y est…).

Cependant, le script a été pensé pour la version Windows de vCenter et il va nous générer des certificats en trop… Mais mieux vaut trop que pas assez ; nous ne prendrons que ce dont nous avons besoin !

Pour générer les certificats, lancez le script Toolkit-55.ps1. Il va commencer par télécharger et installer OpenSSL dans c:\OpenSSL, laissons-le faire. Si votre environnement vous empêche de télécharger OpenSSL, installez-le à la main (URL actuelle – vous pouvez la vérifier dans le script). Puis, nous y voilà :

Vous voyez que le script peut être utilisé dans de nombreuses situations. En ce qui nous concerne, nous sommes intéressés par le choix 8. Faites donc 8, puis entrée. Le script vous demande de nombreuses informations ; soyez attentif !Tout d’abord, le FQDN de l’appliance. Attention à ne pas laisser le nom proposé par défaut ! (c’est celui de la machine qui exécute le script). Ensuite, l’adresse IP. Mettez les guillemets, sinon vous n’aurez pas l’adresse IP dans le “Subject Alternative Name” du certificat, ce qui serait dommage (c’est sans doute un bug du script). Enfin, dernier piège, le certificat pour le vCenter Update Manager doit être le FQDN du serveur Windows sur lequel vous installerez Update Manager, pas celui de l’appliance ! Idem pour Orchestrator, si vous prévoyez de l’installer.

Si vous avez tout bien renseigné, le dossier que vous avez configuré pour stocker les certificats devrait maintenant ressembler à ça :

Notez la présence de dossiers inutiles… Si vous entrez dans un dossier, disons VMware vCenter Service Certificate, vous pourrez (entre autres) trouver votre certificat : rui.crt. N’hésitez pas à l’afficher (double-clic) pour vérifier toutes les informations (Subject avec CN, OU, informations géographiques, Key usage avec Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment, SAN avec le nom court, le nom long et l’addresse IP.

Nous allons maintenant pouvoir passer à l’implémentation des certificats !

Implémentation des certificats sur l’appliance

C’est ici que nous abandonnons Derek et ses outils pour repartir sur la procédure officielle de VMware, à la partie “Installation and configuration of the certificates for all the components”, mais en simplifiant un peu les étapes.

Copie des fichiers

Nous allons commencer par copier nos certificats sur l’appliance. Connectez-vous à votre vCSA avec WinSCP (en root / votre mot de passe), depuis la machine qui héberge les certificats, en utilisant le protocole SCP. La partie de droite affiche le dossier /root sur l’appliance. Créez-y les dossiers suivants dans /root (le dossier par défaut) :

ssl
ssl/vpxd
ssl/inventoryservice
ssl/logbrowser
ssl/autodeploy

La partie de gauche affiche la machine Windows. Positionnez-vous dans le dossier où se trouvent vos certificats.Entrez dans VMware vCenter Service Certificate et copiez rui.crt et rui.key (certificat et clé privée) dans le dossier vpxd.Puis sur le même principe :

Entrez dans VMware Inventory Service Certificate et copiez rui.crt et rui.key dans le dossier inventoryservice.
Entrez dans VMware Logbrowser Service Certificate et copiez rui.crt et rui.key dans le dossier logbrowser.
Entrez dans VMware vSphere Autodeploy Service Certificate et copiez rui.crt et rui.key dans le dossier autodeploy.

Retour à la situation initiale (votre dossier d:\Certificates à gauche) : copiez cachain.p7b à la racine du dossier ssl.

Laissez WinSCP ouvert et connectez-vous en ssh à votre vCSA. Tapez:

cd ssl
openssl pkcs7 -print_certs -in cachain.p7b -out cachain.pem

Cela est censé créer une chaîne de certificats compréhensible par les services VMware (le fichier .pem), mais malheureusement le fichier est pollué par des informations inutiles qu’il nous faut supprimer à la main. Si vous êtes à l’aise avec vi, éditez le fichier cachain.pem et supprimez tout ce qu’il y a avant les lignes —–BEGIN CERTIFICATE—- ou après les lignes —–END CERTIFICATE—–. A la fin, il restera quelque chose comme :

Bien entendu, si vous n’avez qu’une autorité racine, il n’y aura que :

-----BEGIN CERTIFICATE-----
Empreinte du certificat de l'autorité racine
-----END CERTIFICATE-----

Si vous n’êtes pas à l’aise avec vi, vous pouvez télécharger le fichier cachain.pem avec WinSCP sur votre poste, puis l’éditer avec un éditeur qui sait interpréter les fichiers unix/linux (Notepad++ par exemple, mais pas le notepad de Windows !) pour retirer les lignes en trop. Puis, renvoyez le fichier sur l’appliance.

Dernière étape, une fois que vous avez un fichier cachain.pem valide, il faut le copier dans les dossiers inventoryservice, logbrowser et vpxd (autodeploy n’en a pas besoin). Vous pouvez utiliser WinSCP ou la bonne vieille commande cp depuis votre session SSH :

cd
cp ssl/cachain.pem ssl/inventoryservice
cp ssl/cachain.pem ssl/logbrowser
cp ssl/cachain.pem ssl/vpxd

Récapitulons. Sur l’appliance, votre structure de fichiers doit ressembler à ça :

Idem pour les dossiers logbrowser et inventoryservice. Le dossier autodeploy, lui, n’a juste pas de cachain.pem.

Si tout est bon, on peut démarrer la configuration. C’est un très, très bon moment pour faire un snapshot de l’appliance !

Configuration des services vCenter

Commençons par arrêter les services :

service vmware-stsd stop
service vmware-vpxd stop

Créons un certificat complet (notre certificat de service + la chaine de certification)

cd ssl/vpxd
cat rui.crt cachain.pem > chain.pem

On peut alors remplacer le certificat avec la commande :

/usr/sbin/vpxd_servicecfg certificate change chain.pem rui.key

Suspens… Le résultat de votre commande devrait être : VC_CFG_RESULT = 0.

Si c’est le cas, bravo, c’est bon signe pour la suite ! Sinon, vous pouvez vous aider de cette kb pour vous mettre sur la voie.

Redémarrez maintenant le service vmware-stsd :

service vmware-stsd start

Passons au service suivant !

Configuration du service d’inventaire

Nous allons commencer par désenregistrer le service d’inventaire :

cd /etc/vmware-sso/register-hooks.d
./02-inventoryservice --mode uninstall --ls-server https://ma-vcsa.mon-domaine.corp:7444/lookupservice/sdk

Vous devriez voir passer un Return code is: Success, puis le service d’inventaire s’arrêtera. On crée alors un certificat .pem comme précédemment.

cd /root/ssl/inventoryservice
cat rui.crt cachain.pem > chain.pem

Sauf qu’ici, ça ne suffit pas, il faut un certificat au format .pfx. Cela passe par la commande suivante :

openssl pkcs12 -export -out rui.pfx -in chain.pem -inkey rui.key -name rui -passout pass:testpassword

Ne jouez pas au plus malin et laissez testpassword! On copie alors les fichiers dans le dossier du service de certificats.

cp rui.key /usr/lib/vmware-vpx/inventoryservice/ssl
cp rui.crt /usr/lib/vmware-vpx/inventoryservice/ssl
cp rui.pfx /usr/lib/vmware-vpx/inventoryservice/ssl

On modifie les permissions des fichiers.

cd /usr/lib/vmware-vpx/inventoryservice/ssl/
chmod 400 rui.key rui.pfx
chmod 644 rui.crt

On peut enfin réenregistrer le service d’inventaire (il vous faudra le mot de passe de administrator@vsphere.local).

cd /etc/vmware-sso/register-hooks.d
./02-inventoryservice --mode install --ls-server https://ma-vcsa.mon-domaine.corp:7444/lookupservice/sdk --user administrator@vsphere.local --password mdp-administrator@vsphere.local

Si tout s’est bien passé, vous verrez passer Return code is: Success et le service redémarrera. Il nous reste quelques étapes pour réassocier le service avec le service vCenter :

rm /var/vmware/vpxd/inventoryservice_registered
service vmware-inventoryservice stop
service vmware-vpxd stop
service vmware-inventoryservice start
service vmware-vpxd start

Là aussi, vous pouvez guetter le fameux : Return code is: Success.

Service d’inventaire : OK. Au suivant !

Configuration du service Log Browser

Le principe est exactement le même que pour le service d’inventaire. Désenregistrement du service.

cd /etc/vmware-sso/register-hooks.d
./09-vmware-logbrowser --mode uninstall --ls-server https://ma-vcsa.mon-domaine.corp:7444/lookupservice/sdk

Création du certificat.

cd /root/ssl/logbrowser
cat rui.crt cachain.pem > chain.pem

Conversion en pfx.

openssl pkcs12 -export -in chain.pem -inkey rui.key -name rui -passout pass:testpassword -out rui.pfx

Copie des fichiers.

cp rui.key /usr/lib/vmware-logbrowser/conf
cp rui.crt /usr/lib/vmware-logbrowser/conf
cp rui.pfx /usr/lib/vmware-logbrowser/conf

Modification des permissions.

cd /usr/lib/vmware-logbrowser/conf
chmod 400 rui.key rui.pfx
chmod 644 rui.crt

Réenregistrement du service. Comme toujours, guettez le Return code is: Success !

cd /etc/vmware-sso/register-hooks.d
./09-vmware-logbrowser --mode install --ls-server https://ma-vcsa.mon-domaine.corp:7444/lookupservice/sdk --user administrator@vsphere.local --password mdp-administrator@vsphere.local

Redémarrage du service.

service vmware-logbrowser stop
service vmware-logbrowser start

Voilà ! Les trois services obligatoires sont reconfigurés. Si vous en avez vraiment assez (et que vous êtes sûr de ne pas utiliser Autodeploy), vous pouvez redémarrer votre appliance. Mais il serait dommage de s’arrêter là, non ? Allez, un petit dernier !

Configuration du service Autodeploy

La procédure est légèrement différente… Mais plus simple. Ici, on copie directement les fichiers (attention, on les renomme en même temps !).

cd /root
cp ssl/autodeploy/rui.crt /etc/vmware-rbd/ssl/waiter.crt
cp ssl/autodeploy/rui.key /etc/vmware-rbd/ssl/waiter.key

Puis on modifie les permissions et le propriétaire.

cd /etc/vmware-rbd/ssl/
chmod 644 waiter.crt
chmod 400 waiter.key
chown deploy:deploy waiter.crt waiter.key

Et on réenregistre le service. Il pourrait y avoir une erreur sur la commande rm si vous n’avez pas encore démarré le service Autodeploy; c’est normal ! Continuez la procédure.

service vmware-rbd-watchdog stop
rm /var/vmware/vpxd/autodeploy_registered
service vmware-vpxd restart

On attend notre habituel Return code is: Success, et c’est terminé ! Tous les services de l’appliance sont maintenant enregistrés avec vos propres certificats.

On procédera maintenant à un redémarrage complet de l’appliance.

shutdown -r now

Bilan

Pendant que l’appliance redémarre avec ses nouveaux certificats, savourez le plaisir d’avoir terminé cette partie du guide ! Peu d’entreprises prennent le temps de déployer les certificats de leur autorité de certification à l’environnement VMware, alors que cela permet une amélioration conséquente de la sécurité.

Cerise sur le gâteau, vous pouvez oublier les divers avertissements de sécurité qui s’affichent lorsque vous accédez à votre vCenter. Ou bien, si vous en voyez un, c’est que la sécurité du vCenter a été compromise !

Cet article clôt la configuration de notre vCSA, qui est maintenant prête à l’emploi. Mais bien sûr, il reste des choses à faire : préparer une machine pour VMware Update Manager et les outils d’administration (powercli en particulier), et surtout ajouter des hôtes. Et bien entendu, nous mettrons leurs certificats à jour également ! (mais ce sera moins long 🙂 ).