I have a long-standing Azure Cloud Service project, which I use to deploy web and worker roles to Azure from Studio. The cloud service definition and cloud configuration files include information about certificates that have been uploaded to the cloud service. So, in the service definition:
<Certificates>
<Certificate name="cert" storeLocation="LocalMachine" storeName="My" />
<Certificate name="encryption" storeLocation="LocalMachine" storeName="My" />
</Certificates>
and in the service configuration:
<Certificates>
<Certificate name="cert" thumbprint="[hidden]" thumbprintAlgorithm="sha1" />
<Certificate name="encryption" thumbprint="[hidden]" thumbprintAlgorithm="sha1" />
</Certificates>
I have been publishing with these configurations and certificates to the same cloud service for a long, long time with no problems.
Now, I have just upgraded to the Azure 1.7 SDK (June 2012) for Visual Studio 2010 sp1. Once I upgrade my cloud service project [in Properties, click "Upgrade"], I am no longer able to deploy, due to an apparent certificate error:
1:25:28 PM - Connecting... 1:25:33 PM - Error: Certificate: ‘cert’ with Thumbprint: for Role: My.Web has not been uploaded to the cloud service: My Test NC. 1:25:33 PM - Error: Certificate: ‘encryption’ with Thumbprint: for Role: My.Web has not been uploaded to the cloud service: My Test NC.
Notice that there is no Thumbprint listed at all in the error - I did not remove it here for security purposes.
If I edit the project file and change absolutely nothing else besides changing 1.7 to 1.6, once again deployments from Studio work perfectly.
It seems like there is some trouble with Visual Studio sp1 and Azure 1.7, but I haven't found any evidence of anyone else having similar troubles.
UPDATE: I just talked to Microsoft and we're now at least clear on the reproduction steps:
- there have to be multiple service configurations (e.g. "Development" and "Test")
- the different environments have to have different certificates (and therefore different thumbprints).
Since one presumably wouldn't want to store production certificates on development machines (esp. because one wouldn't want development machines to have the ability to decrypt encrypted production values - consider, for instance, if a development laptop got lost), different certificates in different environments seems in line with standard best practices.
So, at this point, Microsoft is going to consider whether or not this is something that needs to get fixed. In the meanwhile, the workarounds for Azure 1.7 SDK are: (1) don't use "publish" from Studio; (2) don't use multiple service configurations; or (3) use the same certificates in all environments (not personally recommended by me).