Quand vCenter 6.0 se rebelle après une expiration de certificat…

Deux jours de galère, de lecture de KB divers zé variés, une douzaine de rollback de snapshots, pour tenter une douzaine de manipulations différentes et enfin, trouver la solution (temporaire). Voila en substance le bilan de l’expiration d’un certificat SSL sur un “vieux” vCenter 6.0 que nous gardons encore pour quelques machines spécifiques.

VMware a fait beaucoup de progrès depuis vSphere 5 concernant la mise à jour des certificats SSL de ses différents produits et solutions. Pour autant, il reste encore des subtilités qui m’échappent, ou des exceptions non documentées (ou peut-être spécifiques à nos environnements) qui font qu’une opération qui, a priori, s’annonçait relativement simple, se transforme en un parcours du combattant. Petit récit de la mésaventure de cette semaine.

Malgré nos efforts pour superviser toujours plus précisément et finement l’ensemble de nos infrastructures techniques, il reste encore des “trous” que nous comblons au gré des revues de supervision régulières et des évolutions de nos produits (roue de Deming tout ça) … et c’est à cause de l’un de ces trous que ce Lundi, nous nous sommes retrouvé dans le noir sur un vCenter 6.0 satellite de notre production principale.

Le symptôme initial était relativement explicite : l’accès au vSphere Client nous renvoyait invariablement une belle erreur 500 :

Après quelques vérifications et manipulations classiques de notre service de MCO (espace disque disponible, reboot etc.), force était de constater que la machine refusait obstinément de nous donner l’accès au client web. La première chose que j’ai trouvé en cherchant un peu dans les logs c’est que le service chargé de la Content Library, aka vmware-vdcs, ne démarrait pas correctement. Pour se faire, j’ai utilisé une manip bien pratique sur les services vCSA :

On visualise très vite quels sont les services arrêtés. Pour certains, suivant les fonctions que vous utilisez, c’est normal, par contre, pour vmware-vdcs, il y avait clairement un problème. Même si je trouvais étrange qu’un service satellite comme celui là provoque un plantage complet du vSphere Client, j’ai creusé un peu et repéré une corruption du fichier “.pid” qui habituellement héberge le process ID du démon. Une petite suppression forcée après, le service se lançait correctement (la note KB#2147891 décrit précisément la situation, à lire).

Malgré ce premier petit souci réglé – ça aurait été trop facile – vCenter refusait encore d’afficher quoi que ce soit. Toujours cette fichue erreur 500. Nos investigations se sont ensuite portées sur les logs des autres services et notamment celui du démon “Component Manager”, ce qui nous a mené sur une autre piste. Celui-ci nous affichait régulièrement des messages d’erreurs sur les certificats SSL en place :

Dieu me tamponne, mais oui… Ooops… le certificat du vCenter était expiré ! Le “trou de supervision” était donc identifié, nous n’avions pas de test d’expiration sur la VCSA. Sur ce constat plutôt rassurant finalement, nous avons donc déroulé la procédure de renouvellement de certificat. Lors de l’installation de la plateforme, nous avions à l’époque installé un certificat issu de notre PKI Infrastructure interne qui reposait sur l’algorithme de hashage SHA-1, dont vous savez certainement qu’il est déclaré “unsecure” depuis déjà un paquet d’années (voir cet article comme tant d’autres, sur Wikipedia). Depuis nous avons créé une nouvelle autorité intermédiaire reposant sur SHA-256, avec laquelle nous certifions désormais tous nos équipements et services de production.

Pour le coup, je me suis dit que nous allions faire d’une pierre deux coups et j’ai entrepris de créer un nouveau certificat via cette nouvelle PKI. La procédure est bien décrite par VMware et repose sur l’utilisation de l’outil “certificate-manager” disponible directement en ligne de commande (pour plus d’info sur son utilisation, consultez le KB#2112277).

Et pourtant, tout semblait être sur la bonne voie pour rétablir l’accès au service rapidement. C’était sans compter sur ce vCenter “tête de mule”. En effet, lors de l’injection du nouveau certificat SSL (tamponné par notre PKI SHA-256, donc, vous suivez ?), le service Component Manager a refusé de démarrer avec encore une erreur de type “Server certificate chain is not trusted” à la clef. Nous sommes reparti à la pèche aux infos via les logs, analyses diverses, beaucoup de lectures sur le Net, pour tomber sur cet article KB#2111571 qui précise qu’il ne faut pas oublier de rajouter la chaîne de certification dans le dépôt officiel de la PSC lorsque l’on injecte un nouveau certificat issue d’une autorité différente. Effectivement, j’avais bien lu cela quelques années auparavant. Dont acte ! Ré-injectons donc cette autorité intermédiaire SHA-256 :

Ensuite, on relance la procédure de remplacement de certificat… et … PAF, et non ! toujours ce satané service Component Manager qui refuse de se lancer ! Incompréhensible, incroyable, frustrant … et les heures qui tournent pendant ce temps là pour notre équipe de prod, sans accès au vCenter. En désespoir de cause, il me vient une idée saugrenue et plutôt “de la dernière chance” : essayons de générer un certificat sur l’ancienne PKI SHA-1 et d’utiliser celui-ci. Ce n’est pas l’idéal et il faudra tôt ou tard corriger cette faiblesse de chiffrement mais si cela permet de rétablir le service rapidement, ce sera déjà ça de gagné.

Je relance donc le certificate-manager avec ce certificat obsolète, mais fonctionnel et dont la date d’expiration laisse le temps de voir venir. Miracle ! Tout ce petit monde redémarre tranquillement et vCenter est de nouveau accessible !

Cette petite “tranche de prod” est encore très fraîche et je n’ai pas encore de root cause identifié vis à vis de ce comportement. Est-ce documenté quelque part ? Aucune idée, en tout cas je n’ai pas trouvé de KB spécifique expliquant le phénomène. La prochaine étape, et bien sûr, je vous tiendrai au courant dans un prochain billet, c’est, alors que le vCenter est à nouveau opérationnel, de tenter de réinjecter un certificat SHA-256 pour vérifier si cela se reproduit. On pourra, en fonction du résultat, tirer des conséquences plus précise de ce qui s’est passé et contacter VMware pour obtenir l’explication.

Mais, vous allez me dire : “pourquoi n’as-tu pas appelé VMware et ouvert un SR ?”. En fait nous l’avons fait au bout de quelques heures de débugging, mais malheureusement, la personne qui a assisté l’ingénieur via webex n’était pas au courant de tous nos tests. Du coup, regardant, comme nous, les logs, le support VMware a répondu, comme nous la première fois, qu’il s’agissait d’un problème de certificat et qu’il fallait en refaire un. En gros, on a trouvé la solution de contournement dans l’intervalle.

Si vous avez des explications de votre coté ou des pistes de réflexions, n’hésitez pas à me les proposer dans les commentaires !

Bonne fin de semaine à vous !