WebApp:az webapp config ssl bind command can not import SSL Certificate from different resource group than WebApp
See original GitHub issueDescribe the bug SSL Certificate imported from GUI (Using KeyVault) for the WebApp “A” residing in ResoureGroup “A”, gets stored as “microsoft.web/certificates” object in the Resource group “A” where the WebApp “A” resides. From GUI, you can add the same certificate to another webapp, as GUI recognizes the certificate even you are adding it in WebApp “B” which is in Resource Group “B”. This is OK if you have less number of apps.
For large organizations, where you have 100’s of WebApps: If you try az command “az webapp config ssl bind” to bind the same thumbprint, you get error: “Certificate for thumbprint ‘XXXXXXXXXXXX’ not found.”
“microsoft.web/certificates” object gets created for each App Service plan for first import of SSL Certificate from KeyVault, which gets stored in the First WebApp where you performed “Import from Keyvault” operation. This object is not movable.
Multiple, certificate objects gets created for multiple App Service Plan, which is not required.
This stops us to make bulk Certificate Addition on multiple webapps.
To Reproduce
- Create two WebApps A & B in two different resource group, i.e. A & B
- Create key vault and import SSL certificate in resource group “KeyVault”
- In Azure Portal, goto WebApp A, import SSL Certificate from Keyvault using the “TLS/SSL settings > Private Key Certificates (.pfx) > Import Key Vault Certificate”
- You will notice that “microsoft.web/certificates” object gets created in Resource Group “A”
- Now open Powershell to run Az Command
- Run following command to add the thumbprint of the certificate to WebApp “B”
az webapp config ssl bind --certificate-thumbprint "XXXXXXXX" --name B --resource-group B --ssl-type SNI
- Command will fail with error : Certificate for thumbprint ‘XXXXXXXXX’ not found. This error occurs because Az command tries to search certificate in WebApp’s Resource group, which is not the actual location of Certificate.
Expected behavior Option A (Preferred)
- “microsoft.web/certificates” object should be avoided if possible, and the certificate should be directly fetched from KeyVault.
- Each app service plan should not have seperate "“microsoft.web/certificates” object, and SSL Certificate should get directly fetched from KeyVault.
Option B
- If, Option A is going to add huge Cost for Read operation of keyvault, then please store the SSL Certificate object “microsoft.web/certificates” in App Service Plan’s “Resource Group”
- Once the object “microsoft.web/certificates” is created in App Service Plan “Resource Group”, you can modify AZ command SSL search location to App Service Plan Resource Group.
- With this method, all the webapps which are residing in their own resource groups can read the certificate and apply it to webapp using az webapp config ssl bind command. This will not limit apps to be residing in single resource group as of “microsoft.web/certificates” Object.
Environment summary azure-cli 2.32.0 core 2.32.0 telemetry 1.0.6 msal 1.16.0 azure-mgmt-resource 20.0.0
Additional context This change will help large environments where there are multiple app service plans and individual Resource groups per WebApps.
Issue Analytics
- State:
- Created 2 years ago
- Comments:7 (3 by maintainers)
Top GitHub Comments
@StrawnSC would be a good one to look at for cross RG scenario for SSL certs, especially when using mixture of clients (portal + CLI for different operations) We can add an ASP argument to this command specifically, that should help.
Looks like there is a related issue where:
This particular user’s issue could be solved by extending
_update_ssl_binding
to also search for certs in the user’s sub and validating the ASP ID