Certificates are used in Azure for cloud services (service certificates) and for authenticating with the management API (management certificates when using the Azure classic portal and not the non-classic Azure portal). This topic gives a general overview of both certificate types, how to create and deploy them to Azure.
Certificates used in Azure are x.509 v3 certificates and can be signed by another trusted certificate or they can be self-signed. A self-signed certificate is signed by its own creator, therefore it is not trusted by default. Most browsers can ignore this problem. You should only use self-signed certificates when developing and testing your cloud services.
Certificates used by Azure can contain a private or a public key. Certificates have a thumbprint that provides a means to identify them in an unambiguous way. This thumbprint is used in the Azure configuration file to identify which certificate a cloud service should use.
What are service certificates?
Service certificates are attached to cloud services and enable secure communication to and from the service. For example, if you deployed a web role, you would want to supply a certificate that can authenticate an exposed HTTPS endpoint. Service certificates, defined in your service definition, are automatically deployed to the virtual machine that is running an instance of your role.
You can upload service certificates to Azure classic portal either using the Azure classic portal or by using the classic deployment model. Service certificates are associated with a specific cloud service. They are assigned to a deployment in the service definition file.
Service certificates can be managed separately from your services, and may be managed by different individuals. For example, a developer may upload a service package that refers to a certificate that an IT manager has previously uploaded to Azure. An IT manager can manage and renew that certificate (changing the configuration of the service) without needing to upload a new service package. Updating without a new service package is possible because the logical name, store name, and location of the certificate is in the service definition file and while the certificate thumbprint is specified in the service configuration file. To update the certificate, it's only necessary to upload a new certificate and change the thumbprint value in the service configuration file.
The Cloud Services FAQ article has some helpful information about certificates.
What are management certificates?
Management certificates allow you to authenticate with the classic deployment model. Many programs and tools (such as Visual Studio or the Azure SDK) use these certificates to automate configuration and deployment of various Azure services. These are not really related to cloud services.
Be careful! These types of certificates allow anyone who authenticates with them to manage the subscription they are associated with.
There is a limit of 100 management certificates per subscription. There is also a limit of 100 management certificates for all subscriptions under a specific service administrator’s user ID. If the user ID for the account administrator has already been used to add 100 management certificates and there is a need for more certificates, you can add a co-administrator to add the additional certificates.
Before adding more than 100 certificates, see if you can reuse an existing certificate. Using co-administrators adds potentially unneeded complexity to your certificate management process.
Create a new self-signed certificate
You can use any tool available to create a self-signed certificate as long as they adhere to these settings:
- An X.509 certificate.
- Contains a private key.
- Created for key exchange (.pfx file).
- Subject name must match the domain used to access the cloud service.
You cannot acquire an SSL certificate for the cloudapp.net (or for any Azure-related) domain; the certificate's subject name must match the custom domain name used to access your application. For example, contoso.net, not contoso.cloudapp.net.
- Minimum of 2048-bit encryption.
- Service Certificate Only: Client-side certificate must reside in the Personal certificate store.
There are two easy ways to create a certificate on Windows, with the
makecert.exe utility, or IIS.
This utility has been deprecated and is no longer documented here. For more information, see this MSDN article.
$cert = New-SelfSignedCertificate -DnsName yourdomain.cloudapp.net -CertStoreLocation "cert:\LocalMachine\My" $password = ConvertTo-SecureString -String "your-password" -Force -AsPlainText Export-PfxCertificate -Cert $cert -FilePath ".\my-cert-file.pfx" -Password $password
If you want to use the certificate with an IP address instead of a domain, use the IP address in the -DnsName parameter.
If you want to use this certificate with the management portal, export it to a .cer file:
Export-Certificate -Type CERT -Cert $cert -FilePath .\my-cert-file.cer
Internet Information Services (IIS)
There are many pages on the internet that cover how to do this with IIS. Here is a great one I found that I think explains it well.
You can use Java to create a certificate.
This article describes how to create certificates with SSH.
Upload a management API certificate to the Azure classic portal.
The Azure portal does not use management certificates to access the API but instead uses user accounts.