Not able to add SSL binding after web app resource moved from one resource group to another

Question

Not able to add SSL binding after web app resource moved from one resource group to another RG in the same subscription

Answer 1

Hello @Ramkumar Sundaresan,

This is often due to conflicts arising from existing IP-based SSL bindings. Specifically, if you see an error message like “Failed to add SSL binding. Cannot set certificate for existing VIP because another VIP already uses that certificate,” it indicates that another App Service instance is using an IP-based SSL binding with the same certificate. This situation occurs because one IP address cannot be bound to multiple certificates across different apps.

To resolve this issue, you can either delete the old IP-based SSL binding that uses the old certificate or create a new IP-based SSL binding with a different certificate. Alternatively, using Server Name Indication (SNI) SSL is recommended, as it allows multiple certificates on a single IP address and is suitable for most scenarios.

---

If this answers your query, do click Accept Answer and Up-Vote for the same. And, if you have any further query do let us know.

Answer 2

Hi @Ramkumar Sundaresan

Thanks @Alex Burlachenko

I’m glad to hear the issue is resolved — thank you for confirming.

Root cause: When a Web App is moved to another resource group, the app resource itself moves, but SSL certificate resources and their permissions don’t always realign automatically. The certificate may remain in the original resource group or temporarily lose access permissions (especially for Key Vault–based certificates). As a result, SSL bindings can fail until the internal references are refreshed or re‑associated.

Resolution: After propagation completed, the SSL references were corrected and the binding became available again. In similar cases, re‑importing or re‑attaching the certificate and recreating the hostname binding resolves the issue.

Microsoft documentation:

• App Service resource move limitations: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/move-limitations/app-service-move-limitations
• Configure SSL bindings in Azure App Service: https://learn.microsoft.com/en-us/azure/app-service/configure-ssl-bindings
• Add and manage TLS/SSL certificates: https://learn.microsoft.com/en-us/azure/app-service/configure-ssl-certificate?tabs=apex%2Crbac%2Cazure-cli

If the answer is helpful,  Please do click "Accept the answer” and Yes, this can be beneficial to other community members.

If you have any other questions, let me know in the "comments" and I would be happy to help you

Answer 3

Ramkumar Sundaresan hi,

when u move a Web App to another resource group the app itself moves, but the certificate resource and its permissions do not automatically fix themselves. SSL bindings depend on the certificate object still being accessible to the Web App in its new scope.

Usually what happens is the certificate did not really move with the app the way u expect. It might still sit in the old resource group and the app simply no longer has permission to use it. If the certificate lives in Key Vault the access rules can also break during the move, so the app suddenly cannot read it anymore. Sometimes the managed identity permissions get out of sync and the app loses the right to access the cert. And in other cases the domain binding is still there but the link to the actual SSL certificate just gets messed up during the move.

Go to TLS/SSL settings and confirm the certificate still appears under Private Certificates. If using Key Vault confirm the app identity still has Get and List permissions on the secret. Try removing the existing hostname binding and recreating it. If needed reimport the certificate into the new resource group.

Moving between resource groups does not always cleanly preserve SSL references, so often the fix is simply reattaching or reimporting the certificate so the binding can be recreated properly.

rgds,

Alex