Azure Management Certificate Public Key / Private Key
Today I'm exploring how the public and private keys created with MakeCert.exe are stored. Earlier I wrote about the difference between SSL certificates and those used for Azure Management API authentication. For this post I'm creating Azure Management API certificates.
I use the certificate creation scripts from a TechNet article I helped create back in 2011. Most of that article is now ancient Azure history but the scripts are still relevant so I'll list them here in case TechNet deletes the article.
Script for creating SSL certificates:
makecert -r -pe -n "CN=yourapp.cloudapp.net" -b 01/01/2000 -e 01/01/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 -sv SSLDevCert.pvk SSLDevCert.cer
del SSLDevCert.pfx
pvk2pfx -pvk SSLDevCert.pvk -spc SSLDevCert.cer -pfx SSLDevCert.pfx -po password
Script for creating Azure Management API certificates:
makecert -r -pe -a sha1 -n "CN=Windows Azure Authentication Certificate" -ss my -len 2048 -sp "Microsoft Enhanced RSA and AES Cryptographic Provider" -sy 24 ManagementApiCert.cer
As you can see the first script creates three files: .cer, .pvk, and .pfx. The second script only creates the .cer file. The .cer file contains the public key of the certificate; you can freely share the .cer file with anyone since it only contains the public key. The .pvk file contains the private key; even though it is password protected you should not share the .pvk file with anyone. The .pfx file stores both the public key and the private key and is password protected. Once you have the .pfx file you don't need the .pvk file anymore.
For the Azure Management API to authenticate a request the .cer file is uploaded to Azure. The caller of the Management API needs the certificate's private key in order to use it as a client certificate for the request.
The question is where is the private key created by the second script? By default MakeCert.exe stores the private key in a key container. If you import the .cer file into the Certificate Store of the computer that issued the MakeCert.exe command, the import process automatically locates the private key. If you instead copy the .cer file to another computer and import it the Certificate Store is not able to locate the private key so you can't use it to authenticate to the Azure Management API.
In the Certificate Store the little key on a certificate icon means it has both the private and public keys for the certificate. An icon without the key means the Certificate Store only has the public key.
If you want to use the Azure Management API authentication certificate on other computers you can add the -sv option to the second script then use pvk2pfx.exe to create the .pfx file as is done in the first script. The complete script for this is:
makecert -r -pe -a sha1 -n "CN=Windows Azure Authentication Certificate" -ss my -len 2048 -sp "Microsoft Enhanced RSA and AES Cryptographic Provider" -sy 24 -sv ManagementApiCert.pvk ManagementApiCert.cer
del ManagementApiCert.pfx
pvk2pfx -pvk ManagementApiCert.pvk -spc ManagementApiCert.cer -pfx ManagementApiCert.pfx -po password
del ManagementApiCert.pvk
What typically happens with me is that I'm using a certificate in my Certificate Store and want to copy it to another computer. Instead of recreating the certificate I export it from the Certificate Store including the private key into a .pfx file that I then import into the other computer. If I'm setting up another Azure subscription and need the .cer file, I export the certificate without the private key and use the DER format. It is less work though when I think ahead and retain the .cer and .pfx files.
When a development team is sharing an Azure subscription or has an automated deployment process it is best to use the script above, store both the .cer and .pfx files in TFS, upload the .cer file into Azure, and then import the .pfx file into any computer that uses the Azure Management API. Then as part of your password reset process periodic repeat the steps above and remove the old certificate from Azure and your computers.
In my next blog post I'll discuss the .publishsettings file.