My latest entry is up on the 10th Magnitude tech blog:
We've taken a little more time than we'd hoped to figure out how to deal with Azure deployment credentials
and profiles properly. In an effort to save other development teams some of our pain, we present our
solution. First, the general principle: Publication profiles are unique to each developer, so each developer
should have her own management certificate, uploaded by hand to each relevant subscription.
When you deploy a project to a Windows Azure Cloud Service instance, you have to authenticate against the
Azure subscription using a management certificate. The Publish Windows Azure Application wizard in Visual
Studio presents you with a helpful link to sign in to your Azure subscription and download credentials. If
you do this every time you publish to a new subscription, you (a) rapidly run up against the 10-certificate
limit in Azure; and (b) get ridiculous credential files called things like
"WorkSubscription1-AzDem12345-JoesSubscription-MySecretProjectThatMyBossDoesntKnowAboutSubscription.publishsettings"
which, if you're not paying attention, soon shows up on a Subversion commit report (and gives your
boss access to that personal project you forgot to mention to her).
Don't do that. Instead, do this:
1. Create a self-signed certificate
using IIS. Name it something clear and unique; I used "david.10thmagnitude.com," for instance.
Then export it to a private folder.
2. Import the .pfx file into your local certificate store.
3. Export the same certificate as a .cer file.
4. Go to the Azure management portal's management certificate list.
5. Upload the certificate you just created to the subscriptions to which you want to publish cloud services.
Now you have a single certificate for all your subscriptions. Next, create a publishing profile with the certificate:
6. In your Azure cloud service project, right-click the project node and choose "Publish…" to bring up the Publish Windows Azure Application wizard.
7. Drop down the "Choose your subscription" list and click "<Manage...>"
8. Click "new"
9. In the "Create or select..." drop down, find the certificate you just created and choose it.
10. Continue setting up your publishing profile as you've done before.
That's it. Except for one other thing.
If you have more than 0 developers working on a project, at some point you'll use source control. Regardless whether
you have Subversion, Mercurial, or whatever, you need to avoid committing keys, certificates, and publishing profiles
into your VCS. Make sure that your VCS ignores the following extensions: *.pfx, *.cer, *.publishsettings, and *.azurePubxml.
You want to ignore pfx and publishsettings files because they contain secrets. (I hope everyone knows this already. Yes, pfx
files use passwords, but publishsettings don't; and anyway, why would you want to risk anyone else authenticating as you
without your knowledge?) Ignore cer files because they're not necessary in an Azure project. And ignore azurePubxml files
because every developer who publishes to Azure will wind up overwriting the files, or creating new ones that no one else uses.