"Le certificat SSL contient un nom commun (CN) qui ne correspond pas au nom d'hôte." dans le déploiement VSTS
J'utilise VSTS pour déployer sur une machine virtuelle Azure. Dans ma définition de version, je reçois l'erreur suivante lorsque j'essaie de copier des fichiers:
Le certificat SSL contient un nom commun (CN) qui ne correspond pas au nom d'hôte. Pour plus d'informations, consultez la rubrique d'aide about_Remote_Troubleshooting.Pour résoudre les problèmes liés à la connexion WinRM, sélectionnez l'option 'Activer les prérequis de copie' dans la tâche. S'ils sont déjà définis et que les machines virtuelles cibles sont soutenues par un équilibreur de charge, assurez-vous que les règles entrantes NAT sont configurées pour le port cible (5986). Applicable uniquement pour ARM = VMs. Pour plus d'informations, veuillez vous référer à https://aka.ms/azurefilecopyreadme };]
Je n'utilise pas d'équilibreur de charge. J'ai remarqué que le problème se produit chaque fois que j'ajoute une étiquette de nom DNS pour mon VM dans le portail Azure (dans les paramètres IP publics).
Le problème n'est pas lié au fichier hôte ou à l'agent de génération, mais plutôt au certificat de serveur sur la machine [~ # ~] cible [~ # ~] . Pour moi, j'utilisais VSTS pour déployer sur une machine virtuelle Azure lorsque j'ai rencontré le problème, mais la solution reste la même pour machines sur site également.
Pour un déploiement Azure VM, le problème se produit lorsque vous créez un VM sans ( étiquette de nom DNS pour votre adresse IP publique, puis ajoutez-en plus tard (quelque chose comme example.centralus.cloudapp.Azure.com). Cela peut également se produire si vous modifiez le libellé du nom DNS.
Problème
Vous voudrez vérifier comment vous vous connectez à la machine. Avant, cela fonctionnait très bien en utilisant l'adresse IP Azure VM. Maintenant, VSTS a commencé à essayer d'utiliser example.centralus.cloudapp.Azure.com:5986 depuis que j'ai récemment ajouté une étiquette de nom DNS. Nous appellerons cela l'adresse de machine cible .
Sur la machine cible , ouvrez PowerShell ou l'invite de commandes en tant qu'administrateur et entrez la commande 'winrm e winrm/config/listener '. Il devrait renvoyer deux écouteurs, un pour [~ # ~] http [~ # ~] et un autre pour [ ~ # ~] https [~ # ~] (si l'un n'est pas répertorié pour HTTPS, ne vous inquiétez pas, nous en ajouterons un plus tard). Portez une attention particulière au nom d'hôte pour l'écouteur HTTPS. Si cela ne correspond pas à l'adresse de la machine cible que nous avons trouvée précédemment, c'est ce qui cause l'erreur. Le CertificateThumbprint correspond à un certificat de serveur sur la machine.
Pour afficher ces certificats, à partir de PowerShell ou de l'invite de commandes, tapez mmc et appuyez sur entrée. Allez dans 'Fichier'> 'Ajouter/Supprimer un composant logiciel enfichable ...'. Sélectionnez 'Certificats' et cliquez sur Ajouter . Dans la boîte de dialogue, sélectionnez 'Compte d'ordinateur' et cliquez sur Suivant puis Terminer . Sous "Certificats"> "Personnel"> "Certificats", vous verrez le certificat utilisé par la configuration WinRM. Les certificats ici auto-signés sont considérés Certificats de test car ils ne sont pas soutenus par une autorité de certification officielle. Nous devrons en créer une qui représente l'adresse de la machine cible que vous souhaitez utiliser.
Vous pouvez également afficher les certificats dans IIS sous ' Certificats de serveur '.
Solution
Assurez-vous de savoir quelle adresse vous souhaitez utiliser pour vous connecter à la machine. Il s'agit de l'adresse de la machine cible .
Sur la machine cible , ouvrez PowerShell en tant qu'administrateur. Entrez la commande suivante.
New-SelfSignedCertificate -DnsName WhateverTargetMachineAddressYouNeed -CertStoreLocation Cert:\LocalMachine\My
Cela crée un nouveau certificat de serveur pour votre adresse cible avec une période de validité d'un an.
Ensuite, nous voulons recréer l'écouteur WinRM pour les types de transport HTTPS afin d'utiliser le nouveau certificat. Ouvrez IIS et regardez Certificats de serveur pour votre serveur Web. Vous devriez voir celui que vous venez de créer. Right- cliquez dessus et sélectionnez "Afficher ...". Dans l'onglet Détails , copiez l'empreinte numérique pour le certificat. Vous pouvez aussi le faire depuis le mmc si vous préférez.
Entrez les commandes suivantes une à la fois dans PowerShell.
winrm delete winrm/config/listener?Address=*+Transport=HTTPS
Ensuite:
winrm create winrm/config/listener?Address=*+Transport=HTTPS '@{Hostname="WhateverTargetMachineAddressYouNeed";CertificateThumbprint="TheThumbprintYouCopied";port="5986"}'
Terminé! Si vous saisissez winrm e winrm/config/listener dans PowerShell, vous devriez maintenant voir le transport HTTPS à l'aide de votre nouveau certificat.
Si quelque chose dans votre définition de version ou vos scripts de déploiement utilise l'ancienne adresse (pour moi, Azure VM)), assurez-vous de les mettre à jour pour utiliser la nouvelle adresse de la machine cible (pour moi, Azure VM) AVEC numéro de port. Dans VSTS, assurez-vous de cocher la case pour utiliser un " Certificat de test ". Bonne chance!
Pour plus d'informations, vous pouvez aller ici: