Home / server / Questions / 1063486
Accepted
JohnLBevan
Asked: 2021-05-14 13:19:55 +0800 CST

MultiSite Azure Application Gateway Error: "Either Data or KeyVaultSecretId must be specified for Certificate"

  • 772

When adding a second multisite HTTPS listener on an application gateway, I get the below exception:

Failed to save configuration changes to application gateway 'MyAppGateway'. Error: Either Data or KeyVaultSecretId must be specified for Certificate 'MyResourceGroup/providers/Microsoft.Network/applicationGateways/MyAppGateway/sslCertificates/myCertificateName'>MyAppGateway/myCertificateName' in Application Gateway.

This error occurs regardless of whether I use the same certificate for both listeners (with the different domains covered by the SAN list), or configure individual certificates per listener.

Once I've hit this error, I can't update the application gateway in any way / the only fix seems to be to delete it.

Is this a known issue, or am I doing something wrong? I'm following the steps as described here; only I'm using a self-signed certificate for the initial SSL cert (i.e. rather than getting LetsEncrypt to issue the initial certificate / since it will be overwritten anyway). When I did a POC of this for a single site all worked as expected; so the issue seems to relate to my use of the multi-site feature (i.e. having different FQDNs pointing to the shared public IP of the app gateway, then routing the requests to different backends based on the host header values).

ssl-certificate azure azure-application-gateway

2 Answers

  1. Best Answer

    Fixing the corrupt application gateway state

    I was able to remove the offending certificate by running the following PowerShell. I couldn't find any option via the portal.

    # Install-Module 'Az.Network' # required for first use
Import-Module 'Az.Network'
$appGw = Get-AzApplicationGateway -ResourceGroupName 'myResourceGroup' -Name 'myAppGateway'
$cert = Get-AzApplicationGatewaySslCertificate -Name 'myCertificateName' -ApplicationGateway $appGw
$cert # see below for info on what this showed

# Delete the cert
Remove-AzApplicationGatewaySslCertificate -Name 'myCertificateName' -ApplicationGateway $appGw | Out-Null #out null because otherwise we see the full updated definition of the app gateway

# Also remove the associated listener, so we don't leave it in an invalid state
Remove-AzApplicationGatewayHttpListener -Name 'myHttpsListener' -ApplicationGateway $appGw | Out-Null

# Update the resource in Azure (earlier commands just updated our local variable/representation of the resource)
Set-AzApplicationGateway -ApplicationGateway $appGw | Out-Null

    By looking at the value of the returned cert (i.e. before we deleted it) we see the problem. The issue wasn't my adding the second certificate, but the first certificate left the gateway in an invalid state, despite having said it was successful when I completed that step.

    Data              :
Password          :
PublicCertData    :
KeyVaultSecretId  :
ProvisioningState : Failed
Type              : Microsoft.Network/applicationGateways/sslCertificates
Name              : myCertificateName
Etag              : W/"00000000-1111-2222-3333-444444444444"
Id                : /subscriptions/mySubscriptionId/resourceGroups/myResourceGroup/providers/Microsoft.Network/applicationGateways/myAppGatway/sslCertificates/myCertificateName

    Root cause

    I experimented with a few options (e.g. LetsEncrypt issued certificates, various certificate names and export passwords). Eventually I found that using an export password which didn't contain the pound (£) symbol and a certificate name which include a hyphen (-) allowed me to create a listener which didn't cause the app gateway to hit a provisioning error / go to an invalid state.

    • 1

  2. I found that if I tried to install the certificate via a keyvault it came up with this error. However if I uploaded the PFX file directly (via the 'listeners' blade in the portal) it worked ok - and if I then went and changed it BACK to getting the certificate from the keyvault it all worked just fine.

    • 1