"The SSL certificate contains a common name (CN) that does not match the hostname." in VSTS Deployment

Question

I am using VSTS to deploy to an Azure VM. In my release definition, I receive the following error when trying to copy files over:

The SSL certificate contains a common name (CN) that does not match the hostname. For more information, see the about_Remote_Troubleshooting Help topic.To fix WinRM connection related issues, select the 'Enable Copy Prerequisites' option in the task. If set already, and the target Virtual Machines are backed by a Load balancer, ensure Inbound NAT rules are configured for target port (5986). Applicable only for ARM VMs. For more info please refer to https://aka.ms/azurefilecopyreadme};]

I am not using a load balancer. I noticed that the issue occurs whenever I add a DNS name label for my VM in the Azure portal (in the public IP settings).

Answer 1

The issue is not with the host file or the build agent, but rather the server certificate on the TARGET machine. For me, I was using VSTS to deploy to an Azure VM when I encountered the issue, but the solution remains the same for onsite machines as well.

For an Azure VM deployment, the issue occurs when you create a VM without a DNS Name Label for your public IP, and then later add one (something like example.centralus.cloudapp.azure.com). It can also occur if you change the DNS name label.

---

Issue

You'll want to check how you're connecting to the machine. Before, it was working just fine using the Azure VM IP address. Now, VSTS started trying to use example.centralus.cloudapp.azure.com:5986 since I had recently added a DNS name label. We'll call this the target machine address.

On the target machine, open up PowerShell or Command Prompt as an administrator, and enter the command 'winrm e winrm/config/listener'. It should return two listeners, one for HTTP and another for HTTPS (if one is not listed for HTTPS, don't worry we'll add one later). Pay particular attention to the Hostname for the HTTPS listener. If this doesn't match the target machine address we found earlier, that is what is causing the error. The CertificateThumbprint corresponds to a server certificate on the machine.

To view these certificates, from PowerShell or Command Prompt, type mmc and press enter. Go to 'File' > 'Add/Remove Snap-in...'. Select 'Certificates', and click Add. In the dialog box, select 'Computer Account' and click Next then Finish. Under 'Certificates' > 'Personal' > 'Certificates', you will see the certificate being used by the WinRM configuration. Certificates here that are self-signed are considered Test Certificates because they are not backed by an official certificate authority. We will need to create one that represents the target machine address you want to use.

You can also view certificates in IIS under 'Server Certificates'.

---

Solution

Make sure you know what address you want to use to connect to the machine. This is the target machine address.

On the target machine, open PowerShell as an administrator. Enter the following command.

New-SelfSignedCertificate -DnsName WhateverTargetMachineAddressYouNeed -CertStoreLocation Cert:\LocalMachine\My

This creates a new server certificate for your target address with a validity period of one year.

Next, we want to recreate the WinRM listener for HTTPS transport types to use the new certificate. Open IIS and look at Server Certificates for your web server. You should see the one you just created. Right-click on it and select 'View...'. In the Details tab, copy the Thumbprint for the certificate. You can also do this from the mmc if you prefer.

Enter the following commands one at a time in PowerShell.

winrm delete winrm/config/listener?Address=*+Transport=HTTPS

Then:

winrm create winrm/config/listener?Address=*+Transport=HTTPS '@{Hostname="WhateverTargetMachineAddressYouNeed";CertificateThumbprint="TheThumbprintYouCopied";port="5986"}'

Done! If you enter winrm e winrm/config/listener in PowerShell, you should now see the HTTPS transport using your new certificate.

If anything in your release definition or deployment scripts is using the old address (for me, the Azure VM IP address), be sure to update them to use the new target machine address (for me, the Azure VM DNS name label) WITH port number. In VSTS, make sure you check the box for using a 'Test Certificate'. Good luck!

For more information, you can go here:

http://www.dotnetcurry.com/windows-azure/1289/configure-winrm-execute-powershell-remote-azure-with-arm