SSL Certificates in Azure: App Gateway and Key Vault
Expired SSL certificates cause production outages. They always expire at the worst possible time, and the fix is always manual and stressful. Storing certificates in Azure Key Vault and linking Application Gateway to it removes the human from the renewal process — Key Vault auto-renews, and Application Gateway picks up the new certificate without a restart.
Your certificate options in Azure
Azure gives you several ways to handle SSL certificates for Application Gateway:
Upload PFX directly. The simplest approach. Export your certificate as a PFX file with the private key and upload it to Application Gateway. Problem: you must repeat this every time the certificate expires.
Key Vault reference. Store the certificate in Azure Key Vault and tell Application Gateway to read it from there. Application Gateway automatically picks up certificate renewals. This is the recommended approach.
App Service Managed Certificate. Only for App Service — not Application Gateway. Azure provisions and renews the certificate automatically for custom domains on App Service plans.
Azure Front Door Managed Certificate. Front Door provisions and renews certificates automatically for custom domains at no extra cost.
Setting up Key Vault for certificates
First, create a Key Vault for certificate storage. Enable soft-delete and purge protection to prevent accidental certificate loss:
az keyvault create \
--name kv-certs-prod-001 \
--resource-group rg-prod-security \
--location eastus \
--sku standard \
--enable-soft-delete true \
--enable-purge-protection true \
--retention-days 90Import an existing PFX certificate into Key Vault:
az keyvault certificate import \
--vault-name kv-certs-prod-001 \
--name cert-myapp-com \
--file /path/to/certificate.pfx \
--password "your-pfx-password"Show certificate details, including expiry date:
az keyvault certificate show \
--vault-name kv-certs-prod-001 \
--name cert-myapp-com \
--query "{name:name, expires:attributes.expires, enabled:attributes.enabled}"Giving Application Gateway access to Key Vault
Application Gateway accesses Key Vault using a User-Assigned Managed Identity. Create the identity, assign it to the gateway, and grant it permissions to read secrets from Key Vault:
# Create a user-assigned managed identity
az identity create \
--name id-appgw-keyvault \
--resource-group rg-prod-networking \
--location eastus
# Get the identity's principal ID
IDENTITY_PRINCIPAL=$(az identity show \
--name id-appgw-keyvault \
--resource-group rg-prod-networking \
--query principalId \
--output tsv)
# Grant the identity access to read secrets from Key Vault
az keyvault set-policy \
--name kv-certs-prod-001 \
--object-id $IDENTITY_PRINCIPAL \
--secret-permissions get \
--certificate-permissions get
# Assign the identity to the Application Gateway
az network application-gateway identity assign \
--gateway-name agw-web-prod \
--resource-group rg-prod-compute \
--identity /subscriptions/<sub-id>/resourceGroups/rg-prod-networking/providers/Microsoft.ManagedIdentity/userAssignedIdentities/id-appgw-keyvaultReferencing a Key Vault certificate in Application Gateway
Get the secret identifier for your certificate in Key Vault:
# Get the secret URI (not the certificate URI — Application Gateway uses the secret URI)
az keyvault certificate show \
--vault-name kv-certs-prod-001 \
--name cert-myapp-com \
--query "sid" \
--output tsvAdd the certificate to Application Gateway using the Key Vault secret URI:
az network application-gateway ssl-cert create \
--gateway-name agw-web-prod \
--resource-group rg-prod-compute \
--name cert-myapp-kv \
--key-vault-secret-id "https://kv-certs-prod-001.vault.azure.net/secrets/cert-myapp-com"Use the secret URI (begins with /secrets/), not the certificate URI (begins with /certificates/). Application Gateway reads the PFX bundle from the secrets endpoint, which includes both the certificate and private key. The certificates endpoint only returns the public certificate without the private key.
Automating certificate renewal
Key Vault can automatically renew certificates issued by supported certificate authorities (DigiCert and GlobalSign). For other CAs or Let’s Encrypt, you can configure Key Vault to create a Certificate Signing Request (CSR) when renewal is needed, then import the signed certificate.
Create a certificate renewal policy in Key Vault:
az keyvault certificate update \
--vault-name kv-certs-prod-001 \
--name cert-myapp-com \
--policy '{
"lifetimeActions": [
{
"trigger": {
"daysBeforeExpiry": 30
},
"action": {
"actionType": "AutoRenew"
}
}
]
}'This triggers renewal 30 days before expiry. When Key Vault creates a new certificate version, Application Gateway automatically detects the update within 4 hours and begins using the new certificate — no manual steps, no restarts, no downtime.
End-to-end SSL configuration
For environments requiring encryption all the way to the backend (compliance, PCI-DSS), configure Application Gateway to re-encrypt traffic to backends:
# Upload the backend's root CA certificate (for validating backend TLS)
az network application-gateway root-cert create \
--gateway-name agw-web-prod \
--resource-group rg-prod-compute \
--name root-cert-backend \
--cert-file /path/to/backend-root-ca.cer
# Update HTTP settings to use HTTPS to backends with certificate validation
az network application-gateway http-settings update \
--gateway-name agw-web-prod \
--resource-group rg-prod-compute \
--name appGatewayBackendHttpSettings \
--protocol Https \
--port 443 \
--root-certs root-cert-backendFor App Service backends with trusted Azure-issued certificates, you can skip uploading a root CA by setting —trusted-client-cert to a built-in trusted CA set. This simplifies end-to-end SSL for App Service without managing your own CA certificates.
Common mistakes
- Setting Key Vault access policy but not the Key Vault firewall. If your Key Vault has a firewall enabled (which it should), you must add Application Gateway’s subnet to the Key Vault’s allowed network list, or enable the “Allow Azure services” bypass. Otherwise Application Gateway gets an access denied when reading the certificate, even with the correct managed identity permissions.
- Not monitoring certificate expiry. Even with auto-renewal configured, you should set up Azure Monitor alerts for Key Vault certificate expiry. Renewal can fail due to domain validation issues, CA outages, or misconfigurations. An alert at 60 days before expiry gives you time to intervene manually.
- Using the certificate URI instead of the secret URI. This is a common copy-paste error. The Key Vault certificate URI (
/certificates/cert-name/version) does not include the private key. Application Gateway cannot create an SSL listener without the private key. Always use the secret URI (/secrets/cert-name).
Summary
- Store SSL certificates in Azure Key Vault and reference them from Application Gateway to enable automatic certificate pickup on renewal.
- Application Gateway uses a User-Assigned Managed Identity to authenticate to Key Vault — grant the identity
getpermissions on secrets and certificates. - Always use the Key Vault secret URI, not the certificate URI, when referencing a certificate in Application Gateway.
- Configure Key Vault’s lifetime action policy to auto-renew certificates 30 days before expiry.
- Monitor certificate expiry with Azure Monitor alerts as a safety net even with auto-renewal enabled.
Frequently asked questions
Should I upload certificates to Application Gateway directly or use Key Vault?
Use Key Vault. Uploading PFX files directly to Application Gateway means you must manually update the gateway each time the certificate renews. With Key Vault integration, Application Gateway reads the certificate automatically and picks up renewals without downtime or manual steps.
Does Application Gateway support Let is Encrypt certificates?
Yes. You can import a Let's Encrypt certificate into Key Vault and reference it from Application Gateway. However, Let's Encrypt certificates expire every 90 days, so you must automate renewal — Key Vault's auto-renewal feature or Azure Certificate Manager handles this.
What is the difference between SSL termination and end-to-end SSL?
SSL termination means Application Gateway decrypts HTTPS traffic and forwards plain HTTP to backends. End-to-end SSL means Application Gateway decrypts the traffic, inspects it, then re-encrypts it before sending to backends over HTTPS. End-to-end SSL adds latency but keeps traffic encrypted to the backend.