Webapp:az webapp config ssl bind: Cannot find certificate in other Resource groups

[iyerusad]

Describe the bug
az webapp config ssl bind needs --certificate-ID parameter.

az webapp config ssl bind cannot find certificates located OUTSIDE of App Service Plan resource group.

Put differently, az webapp config ssl bind will only search App Service Plan resource group for certificate.

This is a problem when App Service Plan is in "SharedPlan" resource group, a web app is in "MyApp" resource group, and the certificate is located "MyApp" in my resource group.

Additionally: az webapp config ssl create will create a certificate in the resource group where the Web App lives, NOT where the App Service Plan lives.

To Reproduce

• Create App Service Plan in resource group named "SharedPlan"
• Create Web App in resource group called "MyApp"
• Create/upload a ssl certificate within resource group "MyApp".
• Attempt to bind uploaded certificate to MyApp using az webapp config ssl bind
• Observe failure to locate certificate thumbpint.

Expected behavior
az webapp config ssl bind should be able to bind a certificate located outside of the AppService Plan resource group. AZ Portal is able to successfully bind this certificate.

An easy solution is parameter for --certificate-ID, rather than relying on certificate thumbprint lookup.

Environment summary
az 2.5.1

Additional context
This is a condensed version of #9972, which was erroneously closed.

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @AzureAppServiceCLI, @antcp.

[yonzhan]

webapp

[panchagnula]

Known issue with API - we are making changes in API - no ETA to share at this point.

[AdamCoulterOz]

I've also run into this (when the serverfarm is in a different rg than the webapp)... in debug mode the az cli clearly switches contexts from searching for the certificate under the webapp to the underlying server farm. Instead of running:

GET /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Web/certificates

with {rg} of the webapp

it runs

GET /subscriptions/{sub}/resourceGroups/{other-rg}/providers/Microsoft.Web/certificates

with {other-rg} of the webapp's serverfarm

When you do the same operation via the portal it does work, seems to get the context right. To perform the bind it does a HTTP request:

PUT /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Web/sites/{webapp}?api-version=2018-11-01

with a JSON body (abbreviated):

{
    "id": "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Web/sites/{webapp}",
    "kind": "app,linux,container",
    "location": "Australia East",
    "name": "{webapp}",
    "type": "Microsoft.Web/sites",
    "properties": {
        "hostNameSslStates": [
            {
                "name": "{FQDN}",
                "sslState": "SniEnabled",
                "ipBasedSslResult": null,
                "virtualIP": null,
                "thumbprint": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
                "toUpdate": true,
                "toUpdateIpBasedSsl": null,
                "iPBasedSslState": "NotConfigured",
                "hostType": "Standard"
            }
        ],
        "hostNames": [
            "{FQDN}"
        ]
    }
}

I was also able to get the bind to work with this newer api (2019-08-01):

PUT /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Web/sites/{webapp}/hostNameBindings/{custom_hostname}?api-version=2019-08-01
Authorization: Bearer {token}
Content-type: application/json

Body:

{
    "kind": "app,linux,container",
    "properties": {
        "azureResoureName": "{webapp}",
        "azureResourceType": "Website",
        "customHostNameDnsRecordType": "CName",
        "domainId": null,
        "hostNameType": "Verified",
        "siteName": "{webapp}",
        "sslState": "SniEnabled",
        "thumbprint": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
    }
}

[AdamCoulterOz]

Thumbprint is also not the best ID to use here, cant we use the certificate ARM ID? e.g.

/subscriptions/{}/resourceGroups/{}/providers/Microsoft.Web/certificates/{custom-domain-name}

as when the certificate gets rotated, it will change the thumbprint

@panchagnula - perhaps that is what is changing in the api?

[cjpluta]

+1 encountering this issue.
Any update to ETA @panchagnula or @singlessis ?

Feel free to ping me on teams, alias is chplut

[giovannifl]

Any update on this ?

[tscamell]

Other than being bumped milestones, is there any update on this please?

[StrawnSC]

Planning on getting the fix in the 8/1/23 release