Set-AzureSubscription : No certificate was found in the certificate store with thumbprint 978C5C139E802DD0A871F5137575E2114C152C3F
So, not sure if it’s related, but this used to work (we’ve not changed any code). It appears to have stopped working AFTER I canceled a deployment that was in-process.
That deployment canceled fine with this result:
Cancelled; terminating the worker process...
Terminated.
Every deployment we’ve attempted since then has failed with the error.
In an effort to fix the situation, I did attempt to go into Configuration > Certificates > “Octopus > Windows Azure” and click the “Generate New” button, however, this apparently does nothing? Is that a bug? When I click that button, nothing appears to happen and if I download the cert using the link, I get the same cert that has always been there. I’m not sure that would have had any effect on my problem but thought it worth mentioning here.
Thanks for getting in touch! The generate new button in Octopus is for Octopus itself and doesn’t have anything to do with Azure, so yeah it’s doing nothing relevant.
Could you call Get-AzureSubscription to find all certificates and then Remove-AzureSubscription to delete them. It should reset this issue and create new ones.
Well, that did not work, but it did help me find the solution. I tried the Get-AzureSubscription and I got the very same error. So, at that point I was stuck - you can’t remove what you can’t even get!
It says you have to manually delete the XML file that the Azure cmdlets store in the user profile. In my case, since Octopus is running this and it runs as Local System on Windows Server 2008, the profile is in this location:
Hi, this issue occurs for us semi-frequently when the Remove-AzureSubscription is called in BootstrapDeployToAzure.ps1.
I’d like to just put a try/catch around it since we really don’t care if it fails, if the subscription isn’t removed it’s no big deal. Unfortunately, we have to actually modify the installation directory to change the file.
Maybe this is a bug in the Windows Azure PS cmdlets, but are there any plans to provide better handling or a way to override the BootstrapDeployToAzure.ps1 file so this can be fixed?
Thanks for letting us know about this! Could I ask for some more detail about what is happening here.
Understanding the specific scenario - what you do, what Octopus does, and how you have to fix it.
We will look into then making the process better, but we don’t feel we have the full story to replicate it yet.
We’ve been unable to reproduce this in an isolated test case and it hasn’t popped up in our real-world deployments again yet - will let you know if we are ever able to repro it again.
We have always been able to run the deployment again after it fails and it will succeed, so it seems transient.