Changement de nom de domaine et certificat

[Arnaud836]

Bonjour,

je souhaite profiter d’une migration KSC12 vers KSC13.2 pour reconfigurer correctement les adresses de connexion des agents, des mobiles et du KSC avec un nouveau nom de domaine public. Actuellement les agents 12 pointent vers ksc.domaine1.fr ce qui permet de gérer les appareils en extérieur.

J’ai configuré le nouveau nom de domaine avec ksc.domaine2.com afin qu’il pointe vers la même adresse IP public (serveur hébergé en interne + redirection du port 13000). Ensuite j’ai généré un nouveau paquet avec l'agent 13.2 pointant vers ksc.domaine2.com (sans certificat) => Le paquet s'installe correctement mais bizarrement d'après klnagchk.exe l'agent pointe toujours vers ksc.domaine1.fr (l'ancien domaine).

1/ Est-ce normal ?

2/ Comment forcer le nouvel agent à pointer vers ksc.domaine2.com ?

Ensuite j'ai exécuté manuellement la commande klmover.exe -address ksc.domaine2.com. L'agent communique correctement avec KSC.

3/ Comment générer un "bon" certificat (pas auto-signé) pour les appareils mobiles et les agents ?

Pour les smartphones, ça semble plus compliqué car le paquet embarque le certificat. Je ne vois donc pas comment migrer vers le nouveau nom de domaine. Si je change le certificat serveur, les mobiles ne communiquent plus avec KSC… :/

4/ Existe-t-il une méthode ?

Merci pour votre aide !

 

[LingNoi]

Bonjour,

Il faut écraser l’agent avec le nouveau certificat SSL pour que la comminucation/l’administration se fasse correctement, puisque c’est un  nouveau Security Center avec un nouveau certificat auto-signé.

 

Pour les téléphones mobiles sous Android, il faudra:

Désinstaller la KESM (possible depuis l’ancien Security Center, il y a une option dans la stratégie pour Android).

Puis renvoyer les invitations pour l’installation du nouveau KESM (KES For Mobile / Android) car il n’y a pas dd’agent pour les mobiles.

 

Cordialement

 

[Arnaud836]

Bonjour LingNoi,

il n’y a qu’un seul KSC… le problème est donc la diffusion du nouveau certificat lié au nouveau FQDN sans perdre la communication avec les agents offline à l’instant T

Depuis mon premier post, j’ai vu qu’il y avait la notion de certificat de réserve avec l'utilitaire klsetsrvcert mais j’avoue ne pas tout comprendre...

Pour les network agents je vais peut être me contenter de déployer une tâche de changement de serveur avec le nouveau FQDN ksc.domaine2.com car j’ai l’impression que l’agent accepte le certificat même lorsque le CN ne correspond pas à l’adresse KSC !

Pour les KESM ce n’est vraiment pas pratique quand il y a toute une flotte de smartphone et qu’on a pas la main sur les appareils… et contrairement aux netagents, KESM ne communique pas avec KSC si l’adresse de KSC ne correspond plus au certificat… J’ai fait le test : j’ai remplacé le FQDN ksc.domaine1.fr par ksc.domaine2.com (qui pointe vers la même IP public pour rappel) => KESM indique une erreur de synchro…

Merci d’avoir lu ce message