How to Install an SSL Certificate on Azure (App Service, Application Gateway and Key Vault)

Where an Azure certificate actually lives

Azure has two certificate stores, and most confusion about Azure TLS comes from not knowing which one is in play. The first is the App Service certificate store. Upload a PFX there and it lands in what Microsoft internally calls a webspace: a deployment unit tied to one combination of resource group, region and operating system. Every app in that same combination can use the certificate. Nothing outside it can, and Application Gateway is outside it.

The second store is Azure Key Vault. A certificate object there is read by App Service and by Application Gateway, each through its own identity and its own refresh schedule. That is the practical reason to use Key Vault even for a single site: the certificate stops being a copy that has to be replaced in several places and becomes one object that everything points at.

A virtual machine running its own web server belongs to neither. There is no binding to configure, no ARN-style handle to attach, and the certificate has to be present as files on the instance exactly as it would be on hardware in a rack. If you would rather not manage TLS on the VM at all, putting an Application Gateway in front of it and terminating there is the usual answer, and the tradeoffs of doing that are covered in our guide to TLS termination and SSL offloading.

Readers coming from the other large cloud will find the shape familiar but the details inverted. AWS takes three PEM files and hands back an ARN; Azure takes one PFX and gives you either a thumbprint in a webspace or a URI in a vault. The comparison is worked through in our companion guide to installing an SSL certificate on AWS, and the third variation is worked through in our guide to installing an SSL certificate on Google Cloud, where two PEM files go in and a certificate map can silently override whatever else is attached to the proxy.

Free managed certificate, or bring your own?

App Service can issue you a free managed certificate that renews itself, and for a single subdomain on a public DNS name it is the right answer more often than people expect. It costs nothing, it is bound automatically, and renewal stops being your problem as long as the DNS records that justified it stay in place. The limits are what rule it out, and they are specific rather than a matter of degree.

Two rows decide most cases. The wildcard row rules out the free certificate for anyone running several subdomains off one name, which is where a wildcard certificate covering *.example.com replaces a per-subdomain pile-up. The export row rules it out for anyone terminating TLS on an Application Gateway or a VM, because a certificate that cannot leave the app cannot be reused anywhere else.

Identity is the third consideration and does not appear in Azure's documentation at all, because it is a property of the certificate rather than of the hosting. A managed certificate proves control of the DNS name. If the site needs the organisation name verified by a CA and present in the certificate, that is an OV or EV product bought from a certificate authority, and the rest of this guide is how it gets installed. You can compare the certificate types we issue if that decision is still open.

Building the PFX that Azure accepts

A private certificate for App Service has to be exported as a password-protected PFX file and has to contain all intermediate certificates and the root certificate in the chain. To secure a custom domain with a TLS binding it also has to carry an extended key usage for server authentication (OID 1.3.6.1.5.5.7.3.1) and be signed by a trusted certificate authority. Those four requirements are the whole specification, and every rejected upload traces back to one of them.

Most CAs deliver PEM files rather than a PFX, so the file usually has to be assembled. Merge the certificate and its chain into one file, in order, with the root at the bottom:

-----BEGIN CERTIFICATE-----
<your certificate>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<intermediate certificate>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<root certificate>
-----END CERTIFICATE-----

Then export it with the private key that generated the request. On OpenSSL 1 the plain command is enough:

openssl pkcs12 -export -out myserver.pfx \
  -inkey private.key -in merged-chain.crt

On OpenSSL 3 that same command produces a file Azure handles differently, because version 3 changed the default PKCS#12 cipher from 3DES to AES-256. Microsoft documents the override explicitly, and it is three flags:

openssl pkcs12 -export -out myserver.pfx \
  -inkey private.key -in merged-chain.crt \
  -keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES -macalg SHA1

This is worth knowing because it makes an unchanged runbook fail. A team that scripted the export years ago, then rebuilt the machine on a distribution shipping OpenSSL 3, gets a PFX that looks correct, opens correctly locally, and behaves unexpectedly on upload. Nothing about the certificate changed; the export cipher did. If your CA sent a format you have not worked with before, the conversions between PEM, DER, PFX and P7B are set out in our reference on SSL certificate formats.

Remember the export password. Azure asks for it when the file is uploaded, and there is no way to recover it from the file afterwards.

Installing on App Service

Uploading and binding are two separate operations in App Service, and the certificate does nothing until the second one is done. Before starting, confirm the App Service plan is in the Basic, Standard, Premium or Isolated tier; the Free and Shared tiers cannot hold a TLS binding, and this is the step that stops people who assumed the certificate was the only cost. The custom domain also has to be added and validated on the app already.

1. In the Azure portal, open the app and go to Certificates.
2. Under Bring your own certificates (.pfx), choose to add a certificate and upload the PFX with its password.
3. Wait for the certificate to appear in the list with the expected thumbprint and expiry date. This is the moment to check that the subject and SAN names match the custom domain, rather than after the binding fails.
4. Go to Custom domains, select the domain, and add a TLS/SSL binding pointing at the uploaded certificate.
5. Choose SNI SSL unless you have a specific reason to use an IP-based binding. SNI is the default for a reason and does not consume a dedicated address.

One property of this store is easy to miss and occasionally useful: a private certificate uploaded to App Service is shared with other apps in the same resource group, region and OS combination, and you can hold up to 1,000 private certificates per deployment unit. Several apps on one wildcard certificate therefore need one upload, not one per app. The flip side is that an app in a different region cannot see it, and the same PFX has to be uploaded again there.

Importing from Key Vault instead

Importing from Key Vault replaces the upload with a reference, and the certificate itself never enters the App Service store as a separate copy. The certificate has to be a PKCS#12 certificate meeting the same requirements as a direct upload. The difference is what happens later: when the certificate is updated in the vault, App Service automatically syncs the new version within 24 hours and updates the bindings that depend on it.

Access has to be granted first, because the App Service resource provider has no access to your vault by default. In the RBAC model, the App Service resource provider — represented as Microsoft.Web in role definitions — needs the Certificate User role on the vault. In the older access policy model the equivalent is a Get permission on secrets and certificates. Do not remove those permissions afterwards as part of a tidy-up; without them the app silently stops syncing new certificate versions.

The reason the figure separates the two services is that granting Key Vault access once does not cover both. App Service reads the vault through its resource provider and needs Certificate User. Application Gateway reads it through a user-assigned managed identity and needs Key Vault Secrets User. Configuring one and assuming the other inherits it produces a gateway that cannot read a vault the web app reads without difficulty, and the error message points at the vault rather than at the role.

Installing on Application Gateway

Application Gateway holds the certificate on its HTTPS listener, and there are two ways to put it there: upload the PFX directly to the listener, or reference a certificate in Key Vault. Uploading works and takes a minute. Referencing Key Vault takes longer to set up and is the option that makes renewal automatic, because gateway instances poll the vault at four-hour intervals and rotate the listener certificate when a newer version appears.

1. Create a user-assigned managed identity and assign it to the Application Gateway. One identity per gateway is the supported arrangement.
2. Grant that identity the Key Vault Secrets User role on the vault, or a Get permission on secrets under the access policy model.
3. If the vault firewall is set to selected networks, add the gateway's virtual network and subnet, enable the Microsoft.KeyVault service endpoint, and allow trusted Azure services to bypass the firewall.
4. On the HTTPS listener, choose the certificate from Key Vault. The portal offers certificate objects; PowerShell, the CLI and ARM templates take a secret identifier URI.
5. If you are supplying the URI yourself, use the versionless form and check it twice. This is the step examined below.

One consequence is worth planning around before it happens. If the gateway cannot reach the vault or cannot find the certificate object in it, Azure sets the listener to a disabled state. Traffic on that listener stops. A rotated managed identity, a firewall rule added during a network cleanup, or a deleted certificate object all produce the same outcome, and it is an outage rather than a warning. Azure Advisor recommendations and Resource Health alerts are where this surfaces, so having those alerts routed somewhere a human reads is part of the install rather than an optional extra.

Renewal: two clocks and one URI

Renewal on Azure is automatic only if the certificate came from Key Vault and the reference to it does not name a version. Application Gateway instances poll the vault every four hours and rotate when a newer version exists; App Service syncs within 24 hours. Any change to the Application Gateway resource — a rule, a tag, a frontend configuration — also forces an immediate check, which is the standard trick for not waiting out the four hours.

The failure mode in the lower branch is the one we see described most often as "Application Gateway is ignoring my renewal". It is not ignoring anything. A secret identifier that ends in a version string, like /secrets/mysecret/a1b2c3, pins the listener to that exact version, so a renewal in the vault is invisible to it. Microsoft recommends a secret identifier that does not specify a version, in the form https://myvault.vault.azure.net/secrets/mysecret/, precisely so the gateway can rotate on its own. The portal generally produces the versionless form; hand-written URIs and infrastructure templates are where the version tends to appear.

How often this matters is no longer a matter of taste. As of March 15, 2026, under the CA/Browser Forum schedule introduced by ballot SC-081v3, a publicly trusted TLS certificate may not exceed 200 days. The same schedule takes the ceiling to 100 days on March 15, 2027 and 47 days on March 15, 2029. A manual PFX upload that felt like a small annual chore under the old 398-day limit becomes roughly twice a year now, about four times a year in 2027, and something close to monthly in 2029. That trajectory, rather than any feature of Azure, is the argument for putting the certificate in Key Vault and pointing a versionless URI at it. The wider picture of the schedule is covered in our guide to shorter certificate lifetimes.

A note on the free managed certificate, since it renews itself and therefore looks exempt: its renewal depends on the DNS configuration that justified it still being valid. A subdomain certificate needs a CNAME mapped directly to <app-name>.azurewebsites.net — an intermediate CNAME in the path blocks both issuance and renewal. An apex domain needs an A record to the app's IP address and is not supported on root domains integrated with Azure Traffic Manager. A DNS change made for unrelated reasons can quietly end the automatic renewal.

Why Azure rejects a certificate that looks fine

Nearly every rejected upload comes down to the file rather than to Azure, and there are four common causes. Working through them in order resolves the large majority of cases without opening a support ticket.

1. An incomplete chain. The PFX has to contain all intermediates and the root. A file exported from a browser or a certificate manager frequently contains the leaf alone, and it will look perfectly valid when you inspect it.
2. A newer OpenSSL than the runbook assumes. Version 3 exports with AES-256 by default. Re-export with -keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES -macalg SHA1.
3. A missing server authentication EKU. A certificate issued for client authentication, email, or code signing lacks OID 1.3.6.1.5.5.7.3.1 and cannot be used in a TLS binding, regardless of how the names look.
4. A plan tier that cannot hold a binding. On Free or Shared the upload may succeed while the binding is unavailable, which reads as a certificate problem and is a plan problem.

For Application Gateway the diagnostic order is different, because the file is rarely the issue. Check the managed identity still exists and still holds Key Vault Secrets User; check the vault firewall has not been narrowed since the gateway was configured; check whether the listener has been set to a disabled state, which tells you the gateway lost access rather than rejected the certificate. When an import that worked last year fails today with unchanged tooling, look at what changed around it — an intermediate the CA rotated between orders, a rebuilt build agent, a tightened network rule — rather than at the certificate itself.