More fun with Certificates

I ran across another problem while trying to upload another VHD to Azure. I had decided to upgrade my HPC head node to Service Pack 3 (the Release Candidate is available on https://connect.microsoft.com/hpc) and when I tried to spin up the Azure VMRole compute nodes based on the VHD that I had uploaded previously, I discovered that they would never finish provisioning. An hour after the provisioning log indicated that the Azure operation succeeded - and the status of all the nodes in the Management Portal indicated "Ready", the provisioning log stated "Node AZURE\AzureCN-001 never became available, and the state changed to "Offline".

I realized that the problem was probably the mismatch between SP2 on the VMRole nodes and SP3 on the HPC head node. So, I created a differencing VHD and fired up a new Virtual Machine, uninstalled the HPC Pack, and installed the HPC Pack with SP3. After running sysprep, I tried to upload the new VHD to Azure storage using the csupload utility, but I encountered this error:

Cannot contact server Could not establish secure channel for SSL/TLS with authority 'management.core.windows.net'.

After scratching my head for some time, it dawned on me that I might have a problem with the certificate, even though the connection parameter specified the same certificate that I had used successfully in the past.

I have also been working on some of the learning exercises in the Windows HPC with Burst to Windows Azure Training Course available here:

https://msdn.microsoft.com/en-us/HPCAzureBurstTrainingCourse

A couple of those examples leverage the REST API's for submitting jobs to the HPC scheduler. As part of that setup, there is a step where I was given a choice to select a certificate for binding to port 443, and I can’t remember which certificate I chose, but it was obviously not the same one that I had been using for the Azure connections.

So,I opened a command prompt and ran this command to determine which certificate was bound to port 443:

netsh http show sslcert

I then opened up the MMC console, and learned a new trick.  I added the Certificate snap-in twice – once for the Local Machine, and once for the Current User.  This saved me having to do an export from one and import to the other as I described in my earlier blog post.  After I located the certificate in the Trusted Root section of the Local Machine store, I exported it to the desktop so that I could add it to my Azure Management certificates then simply dragged it to the
Personal section of the Current User store.

Once I added it to my Management Certificates through the Azure Management Portal, I ran the

csupload Set-Connection

command to specify the new certificate, then I was able to upload the new VHD with no other problems.

The moral to the story is – Make sure that the same certificate is being used for both the REST SSL port binding and the csupload connection.