Flash on Zwindler's Reflection

vSphere Web Client : VMware Lookup Service SSL certificate verification Failed

Tue, 08 Aug 2017 11:30:25 +0000

Qui a entendu du VMware Lookup Service ?

[Aparté]M4vr0x ayant pas mal monopolisé le temps de parole sur Proxmox VE, je retourne un peu sur VMware histoire de changer un peu, mais rassurez vous, d’autres articles sur le clustering vont suivre ;-).[/Aparté]

Un matin d’astreinte comme les autres. On me réveille aux aurores car un serveur Business Object est encore dans les choux. Le serveur Windows qui l’héberge (je ne vous donnerai pas la version, vous allez vous moquer) est encore en carafe, encore pour une raison obscure (pas de pb de RAM, pas de charge CPU, pas de pic d’IO… normal ?).

C’est une vieille infra client, sur laquelle je n’ai plus trop mon mot à dire : elle n’est plus sous ma responsabilité directe, en dehors de l’astreinte. Mais j’ai quand même encore les accès en console VMware pour me connecter et regarder ce qui ne va pas.

Dans le doute, reboot. Si ça rate, reformate.

Un des hymnes de l’IT au bureau. Roy et Moss approuveraient.

Depuis quelques temps, j’ai des soucis avec mon client lourd vSphere. La console ne s’affiche pas en entier, du coup je ne vois que le quart supérieur gauche de l’écran, ce qui est relativement handicapant.

![](/2017/08/vsphere.avif

Ok je fais comment là ?

De toute façon comme il est déprécié et censé disparaitre depuis des années (la 5.5 je crois ?), je n’ai pas pris la peine de chercher pourquoi et n’utilise plus que le client Web, malgré sa lenteur épique sur les plus vieilles versions.

Manque de chance, un message d’erreur m’attend au login !

Failed to connect to VMware Lookup Service. SSL certificate verification failed

L’erreur a le mérite d’être assez clair. Quelque part, il y a un service qui se charge de vérifier un certificat et ce certificat est mauvais ! Heureusement on trouve pas mal de ressources en anglais sur le sujet, notamment chez Yellow bricks (pour la 5.1, lui).

« Lorsque vous modifiez le nom d’hôte de vCenter Server Appliance, une erreur Lookup Service apparaît lorsque vous redémarrez le dispositif. »

OK. Qui est le saucisson qui a modifié le hostname mais ne s’est pas logué après pour vérifier que ça fonctionnait ?

C’est donc tout simplement un certificat qui n’est plus valide car le nom d’hôte a changé.

On peut facilement corriger le problème en se connecter sur l’application d’administration de la VCSA. Vous l’avez utilisée lors de l’installation de l’appliance, via l’URL https://@IP_ou_FQDN_vcenter:5480.

Il faut se connecter avec le compte root de l’appliance, choisi au moment de l’installation.

Naviguez jusqu’à trouver l’onglet Admin. A partir de là, sur la 5.5, il y a un bouton radio qui permet de régénérer automatiquement les certificats si nécessaire. Passez le à « oui ». Idéalement il faudra penser à l’enlever une fois le problème réglé, pour d’évidentes raisons de sécurité.

La documentation officielle indique que redémarrer les services ne suffisent pas. Il est donc réellement nécessaire de rebooter complètement l’appliance car la régénération des certificats se fait au reboot.

Ne cliquez pas sur « Reset », ça efface tous le champs. J’en aurai une bonne à vous raconter à ce sujet d’ailleurs ;-).

Après le reboot, l’erreur sur le vsphere web client sur https://@IP_ou_FQDN_vcenter:9443 devrait avoir disparue !

Unable to connect to server

Tout est bien qui fini bien ? Non ! Si vous essayez comme moi de retourner sur le serveur de configuration du vCenter (pour prendre des captures d’écran et faire un article de wiki ou de blog par exemple), vous ne pourrez plus vous connecter. Après le login vous aurez le message suivant qui apparaitra en rouge :

Unable to connect to server

En réalité, c’est simplement un problème de cache de votre navigateur web. Il faut vider votre cache navigateur et accepter le nouveau certificat qui vient d’être régénéré.

Source

www.yellow-bricks.com/2012/12/19/failed-to-connect-to-vmware-lookup-service-ssl-certificate-verification-failed/
pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.troubleshooting.doc%2FGUID-D9ACB836-2BB4-4DDC-9383-91EF6E546A30.html (lien mort comme absolument tout chez VMware)

Debug : Client NTP Linux vers NTP Windows Server

Sat, 05 Sep 2015 10:30:12 +0000

Si vous travaillez comme moi dans un contexte mixant les serveurs Linux et des serveurs Windows, vous avez probablement un serveur Active Directory pour gérer votre annuaire d’entreprise (ou au moins gérer vos serveurs Windows dans un ensemble cohérent).

Et comme les serveurs Windows dans un domaine Active Directory sont tous automatiquement synchronisés sur le temps du serveur maitre de l’AD, vous vous êtes probablement dit que ça serait une bonne idée de synchroniser tout le monde sur le même serveur.

Ou alors, vous avez un vieux serveur Windows connecté à une horloge hertzienne (ou autre, GPS, etc) et vous voudriez qu’il serve de source de temps fiable.

Mais rien n’y fait, ces fichus linux refusent de se mettre à jour ! Pourquoi ?

Configurer notre NTP Windows

w32time est il un serveur NTP ?

D’abord, avant de vous lancer, il faut que vous sachiez que Microsoft n’a pas fait un boulot terrible avec w32time. On ne peut pas vraiment qu’il s’agit d’un « vrai » serveur NTP. En fait, il s’agit plutôt d’une adaptation du service du temps w32time pour servir de serveur aux éventuels clients assez fous pour demander l’heure.

A ma connaissance, w32time n’a même pas de « driftfile » : si la source de temps n’est pas disponible et que l’horloge interne du serveur dérive, le serveur sera incapable de se corriger de lui même et votre heure se décalera de plus en plus.

Pour en terminer avec ce démontage en règle, c’est tellement du bidouillage qu’une des méthodes les plus répandues pour configurer le « serveur de temps » Windows consiste à modifier des clés de registre. Moi je vous donne la version « lignes de commandes », mais bon, tout est dit…

Méthode ligne de commandes

Si le serveur Windows en question est un serveur Active Directory, vous pouvez passez à l’étape « Linux » de l’article, car le serveur w32time est déjà configuré

Toutes les commandes sont à entrer dans un prompt « administrateur »

Couper le temps windows

net stop w32time

Synchroniser le serveur par rapport à une source de temps (soit un autre serveur NTP, soit l’horloge locale)

w32tm /config /syncfromflags:manual /manualpeerlist:[hostname] #si on souhaite connecter ce serveur à un autre serveur (sur Internet ou local)

w32tm /config /syncfromflags:manual #s'il n'y a pas de "père" et qu'on veut prendre la "local clock" comme source de temps

Pour information, on peut spécifier plusieurs serveurs dans [hostname], il faut juste les séparer par des virgules

Définir le serveur en tant que source de temps fiable

w32tm /config /reliable:yes

Relancer le temps windows

net start w32time

Afficher la configuration

w32tm /query /configuration

Resynchronisation (dans le cas où vous avez spécifié un serveur dans manualpeerlist)

w32tm /resync /rediscover

Et la méthode regedit alors ?

Les clés de registre à modifier se situent dans le noeud de registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config. Principalement, vous devrez modifier AnnounceFlags et NTPServer pour indiquer que vous êtes serveur NTP

Vous trouverez les valeurs des clés de registre sur la page officiel du support à l’adresse suivante :

support.microsoft.com/fr-fr/kb/223184

Mais rien n’y fait, ces fichus Linux refusent de se mettre à jour ! Pourquoi ?

Je ne vais pas couvrir ici comment installer le client NTP sur les serveurs Linux, il y a suffisamment de documentations et de blogs qui traitent du sujet. Ce qu’ils expliquent plus rarement en revanche, c’est comment ça se fait que les clients NTP Linux refusent le temps provenant d’un serveur Windows.

Assurez vous déjà de ne pas avoir laissé plus de « restrict » que nécessaire. En effet, pas sécurité, les clients NTP sont souvent paramétrés de manière très sécurisée, ce qui est bien mais génère souvent des erreurs.

Voici un exemple de fichier de configuration minimaliste pour un client NTP sur un serveur RedHat Entreprise Linux

cat /etc/ntp.conf
server ntp1.mondomaine.fr iburst #enlever iburst hors debugging
server mondomaine.fr
server serveurntp.de.linternet.fr
driftfile /var/lib/ntp/drift

Et c’est tout. Dans la plupart des contexte, vous n’aurez pas besoin de plus. Et comme le mieux est l’ennemi du bien …

Je n’ai pas de restrict, et ça ne fonctionne toujours pas !

Tout à l’air correct, votre client Linux est paramétré pour se connecter sur les serveurs Windows, le démon tourne, mais ça ne fonctionne pas.

C’est la que le « fun » commence vraiment : on va débuguer NTP.

Pour ça, je vous propose d’utiliser la commande ntpq et ses nombreuses fonctions, qui soyons honnête, n’est pratiquement jamais utile, à part dans des cas comme ça !

# ntpq
ntpq> peers
remote refid st t when poll reach delay offset jitter
==============================================================================
ntp1.mondom 111.0.111.151 4 u 34 64 377 0.272 -184.31 9.019

Ici, j’affiche les serveurs NTP avec la fonction peers. Je n’ai paramétré que le serveur Windows ntp1.mondomaine.com pour simplifier le diagnostic.

Normalement, tout à gauche, juste avant le nom, je devrais avoir un symbole * qui indique que le client s’est connecté à ce serveur, ou éventuellement + pour annoncé que le serveur est utilisable (si vous avez plusieurs serveurs).

Ici ce n’est pas le cas. Avec la fonction as, on peut obtenir plus d’informations.

ntpq> as
ind assID status conf reach auth condition last_event cnt
===========================================================
1 8950 9014 yes yes none reject reachable 1

Mon serveur ntp1 avec l’ID assID=8950 est en condition reject, malgré qu’il soit reachable. Ce n’est donc pas un souci réseau ou pare-feu. Pour avoir plus de détails, on peut utiliser la fonction rv, qui prend en argument l’assID du serveur

ntpq> rv 8950
assID=8950 status=9014 reach, conf, 1 event, event_reach,
srcadr=ntp1.mondomaine.com, srcport=123, dstadr=111.0.111.130,
dstport=123, leap=00, stratum=4, precision=-6, rootdelay=93.750,
rootdispersion=10329.788, refid=111.0.111.151, reach=377, unreach=0,
hmode=3, pmode=4, hpoll=6, ppoll=6, flash=400 peer_dist, keyid=0, ttl=0,
offset=-184.319, delay=0.272, dispersion=17.890, jitter=7.364,
reftime=d58e6c8b.deb41e80 Mon, Jul 15 2013 14:41:47.869,
org=d58e6cf5.7eb41e80 Mon, Jul 15 2013 14:43:33.494,
rec=d58e6cf5.adb21a64 Mon, Jul 15 2013 14:43:33.678,
xmt=d58e6cf5.ad9d86ac Mon, Jul 15 2013 14:43:33.678,
filtdelay= 0.31 0.30 0.29 0.27 0.36 0.35 6.65 1.05,
filtoffset= -183.41 -183.41 -183.98 -184.32 -185.32 -192.70 -173.01 -170.95,
filtdisp= 15.63 16.57 17.56 18.51 19.45 20.40 21.37 22.33

Qu’est ce qu’il faut comprendre là dedans ?

Ce qui va vraiment nous aider à comprendre le souci ici, c’est le code flash, qui peut d’ailleurs vous servir si vous avez d’autres problème de NTP complexes à débuguer :

The flash status word is displayed by the ntpq program rv command. It consists of a number of bits coded in hexadecimal as follows:
Code Tag Message Description
0001 TEST1 pkt_dup duplicate packet
0002 TEST2 pkt_bogus bogus packet
0004 TEST3 pkt_unsync server not synchronized
0008 TEST4 pkt_denied access denied
0010 TEST5 pkt_auth authentication failure
0020 TEST6 pkt_stratum invalid leap or stratum
0040 TEST7 pkt_header header distance exceeded
0080 TEST8 pkt_autokey Autokey sequence error
0100 TEST9 pkt_crypto Autokey protocol error
0200 TEST10 peer_stratum invalid header or stratum
0400 TEST11 peer_dist distance threshold exceeded
0800 TEST12 peer_loop synchronization loop
1000 TEST13 peer_unreach unreachable or nonselect

Ici, 400 peer_dist signifie que le « distance threshold » du serveur Windows (un paramètre à priori arbitraire puisqu’on peut le changer comme on le souhaite) est considéré comme trop important par le client NTP. Il y a donc deux méthodes pour résoudre ce problème :

Les solutions

Côté Linux

Dans votre configuration NTP, vous pouvez ajouter la ligne suivante, puis redémarrer le client NTP.

cat /etc/ntp.conf
[...]
tos maxdist 20 #utile pour les serveurs windows qui par défaut on un localclockdisp à 10 secondes par défaut
#sinon le débuging NTP loguera un condition reject sans plus de détails
#Ce paramètre windows est d'ailleurs modifiable avec un w32tm /config /localclockdisp X

Au bout de quelques secondes il devrait se synchroniser (vous pouvez vérifier avec ntpq -p ou ntpstat)

watch "ntpq -p"

ntpstat ntp2.mondomaine.com
synchronised to NTP server (111.0.111.13) at stratum 2
time correct to within 10100 ms
polling server every 64 s

Côté Windows

A l’inverse, vous pouvez tout à fait décider d’abaisser la dispersion au maximum (sous 3 secondes, je crois que ça fonctionne) sur le serveur Windows.

w32tm /config /localclockdispersion:3 /update
w32tm /resync /rediscover

Le client Linux devrait alors se montrer plus coopératif

ntpstat
synchronised to NTP server (111.0.111.147) at stratum 2
time correct to within 3046 ms
polling server every 64 s

Ressources utiles

Pour en arriver à écrire cet article, je peux vous dire que j’ai passé pas mal de temps à fouiller Internet. Voici l’ensemble des ressources qui m’ont aidé à trouver la solution :

NTP 4 pour Windows

www.eecis.udel.edu/~mills/ntp/html/hints/winnt.html (lien mort, j’utilise Internet Archive)

Debuguer NTP

Wiki du support NTP officiel

support.ntp.org/bin/view/Support/ConfiguringNTP NTP serveur pour Windows (interaction avec Linux)
yadhutony.blogspot.fr/2012/10/ntp-time-server-configuration-in.html
blog.galsungen.net/?tag=ntp
inf0blog.canalblog.com/archives/2010/07/27/18679194.html

Codes NTP

www.eecis.udel.edu/~mills/ntp/html/decode.html#flash (lien mort, j’utilise Internet Archive)