Azure SSL verses Management API Certificates
It is important to distinguish the difference between digital certificates intended for SSL endpoints and those intended for use with the Azure management API. Azure doesn’t care where the cert’s come from but the certs for SSL have to be issued by a Certificate Authority (CA) that the calling client trusts or the client’s browser will display a warning and WCF calls fail; these are the cert you usually have to purchase. People familiar with purchasing SSL certs for IIS will understand the requirements.
For Microsoft OS’s the list of Trusted Root CA’s is maintained here (Windows) and here (WP7). The SSL cert must have a name which matches your web site’s domain name and hence a DNS CNAME entry is required to map yourapp.cloudapp.net to www.yourcompany.com since a CA will only issue cloudapp.net certificates to Microsoft.
Azure doesn’t care about the root CA of the digital certs used to authenticate with the management API. These are called Management Certificates and Azure’s only requirement is that the certificate be at least 2048 bits long. Azure just compares that the cert you provide during the API call matches one, of up to five, Management Certificates an administrator previously uploaded.
Self-signed Management Certificates are perfectly acceptable; plus they are easy and free to create using MakeCert.exe or the IIS management console. This is good as you should create new ones to replace old ones periodically as part of your overall password reset policy and when personnel with access to the old certificates leave your organization.
The management portal only uploads SSL certificates in the Personal Information Exchange (.pfx) file format and Management Certificates in the X.509 (.cer) file format. This link describes working with both of these certificate file formats:
https://msdn.microsoft.com/en-us/library/gg432987(v=MSDN.10).aspx
Comments
Anonymous
February 15, 2011
Hi David, I hope this is an easy question to answer as I think I’ve got most of my SSL steps done. However, when I want to add SSL to my Azure website do I create the CSR to point to "MYAZUREAPP.cloudapp.net" or do I create it for "www.mydomain.com" (the user-friendly URL that is pointing to MYAZUREAPP.cloudapp.net)? I do have the user friendly domain pointing to my cloud url so that is working fine. Also, the www.mydomain.com is going to have many sub-domains added to it so we’ll have “cname1.mydomain.com”, “cname2.mydomain.com” etc. I have purchased the SSL certificate from GoDaddy. I just need to submit the CSR to it to get the ball rolling. I think I understand the rest of it i.e. uploading the certificate to Azure and referencing it in my Azure Web Role solution. Thanks in advance for any help you can offer. Cheers, MikeAnonymous
March 30, 2011
Hi Mike, All of your CSR requests to an official CA such as GoDaddy need to be for a domain name that you own. Microsoft owns cloudapp.net so you'll request certificates for your domain, mydomain.com. The only cloudapp.net certificates you can create are the self signed variety used during development and testing. I discuss self signed certificates in this TechNet article: technet.microsoft.com/.../gg607453.aspx There is also a more advanced batch script for self signing in the WP7CertInstaller sample on CodePlex: wp7certinstaller.codeplex.com PS: Sorry for the delay, I just found your comment over in the spam area. David...