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: