Certificates overview for Azure Cloud Services (classic)


Cloud Services (classic) is now deprecated for new customers and will be retired on August 31st, 2024 for all customers. New deployments should use the new Azure Resource Manager based deployment model Azure Cloud Services (extended support).

Certificates are used in Azure for cloud services (service certificates) and for authenticating with the management API (management certificates). 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 contains 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.


Azure Cloud Services does not accept AES256-SHA256 encrypted certificate.

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 either using the Azure 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 - Configuration and Management 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.

Additionally, management certificates can not be used with CSP subscriptions as CSP subscriptions only support the Azure Resource Manager deployment model and management certificates use the classic deployment model. Reference Azure Resource Manager vs classic deployment model and Understanding Authentication with the Azure SDK for .NET for more information on your options for CSP subscriptions.

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 public key.

  • Created for key exchange (.pfx file).

  • Subject name must match the domain used to access the cloud service.

    You cannot acquire a TLS/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" -KeyLength 2048 -KeySpec "KeyExchange"
$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.


This article describes how to create certificates with SSH.

Next steps

Upload your service certificate to the Azure portal.

Upload a management API certificate to the Azure portal.