App Service Certificate Out of Sync and DOES NOT SYNC Take II

Question

App Service Certificate Out of Sync and DOES NOT SYNC Take II

Mike-E-angelo 631

This is in regard to this issue:

https://learn.microsoft.com/en-us/answers/questions/5734127/app-service-certificate-out-of-sync-and-does-not-s

The related Microsoft Case #2602190040001844 was closed without explanation, and the issue still persists. Why are you opening tickets and closing them without the customer's confirmation? I hope you can understand the concern, and that the concern is understandable. Please help.

Golla Venkata Pavani 2,340 Reputation points Microsoft External Staff Moderator

2026-02-27T21:25:08.04+00:00
Hi @Mike-E-angelo ,

Thank you for reaching us regarding the issue.

From the backened logs and the screenshot now shared, you can see that the account that was asked to be added has only "Key Vault Reader" role and not "Key Vault Certificates Officer".

If using RBAC instead of access policies, ensure equivalent roles are assigned at the vault scope, for example via:

az role assignment create --role "Key Vault Certificates Officer" --assignee "f3c21649-0979-4721-ac85-b0216b2cf413" --scope /subscriptions/{subscriptionid}/resourcegroups/{resource-group-name}/providers/Microsoft.KeyVault/vaults/{key-vault-name}

This explains why the Sync operation reports successful it validates the linkage metadata but the backend operation that reads or updates the secret fails silently due to insufficient secret permissions. As documented by Microsoft, the CertificateRegistration service principal must have secret-level access to the Key Vault for renewal to complete properly.

Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.
Mike-E-angelo 631 Reputation points

2026-02-28T08:51:05.5533333+00:00

Hi @Golla Venkata Pavani thank you for your reply.

As documented by Microsoft, the CertificateRegistration service principal must have secret-level access to the Key Vault for renewal to complete properly.

Can you please provide the exact location and URL for this documentation? As you can see from the history of the previous thread, Key Vault Certificates Officer was never recommended by either of your agents. Indeed, via Private Message (which is no longer available because it was ... removed? please explain) @Shree Hima Bindu Maganti suggested Key Vault Secrets User and this did not work, either.

Before I continue to add even more permissions that may or may not work, can I please get an explaination from you for why ticket #2602190040001844 was closed without customer confirmation? I hope you can understand the concern. Thank you for your assistance.
Shree Hima Bindu Maganti 6,890 Reputation points Microsoft External Staff Moderator

2026-02-28T13:50:55.62+00:00
Hi @Mike-E-angelo
Apology for your inconveniences
Thank you for your patience. Based on backend validation, the issue appears to be permission-related. From the screenshot shared, the relevant service principal currently has the Key Vault Reader role, which only provides read access. It does not allow certificate or secret write operations required for renewal and synchronization.

For App Service Certificate renewal to complete properly, the Microsoft.Azure.CertificateRegistration service principal must have certificate-level permissions in Key Vault.

For your reference: https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-guide?tabs=azure-cli

For your reference: https://learn.microsoft.com/en-us/azure/key-vault/general/about-keys-secrets-certificates#access-policies

The Key Vault Reader role does not grant secret or certificate write permissions. Roles such as:

Key Vault Certificates Officer

Key Vault Secrets Officer

Key Vault Administrator

are required for managing certificates and secrets.

Please assign the following role to the Microsoft.Azure.CertificateRegistration service principal:

az role assignment create \ --role "Key Vault Certificates Officer" \ --assignee "f3c21649-0979-4721-ac85-b0216b2cf413" \ --scope /subscriptions/{subscriptionid}/resourcegroups/{resource-group-name}/providers/Microsoft.KeyVault/vaults/{key-vault-name}

Alternatively, this can be done in the Azure Portal:

Key Vault → Access control (IAM) → Add role assignment → Select Key Vault Certificates Officer → Assign to Microsoft.Azure.CertificateRegistration

After assigning the role, please retry the Sync operation.
Let me know if you have any further assisstences needed.
Mike-E-angelo 631 Reputation points

2026-02-28T14:30:17.6033333+00:00

Hi, thank you for your reply, and there is certainly something amiss here, as I replied to your private message in the other thread showing you the permissions, and the problem still persisted. Closing a ticket is one thing, but closing a private message as a backup communication seems even worse as it deletes previous history and important details. If it's ok with you, let's please no longer use private messages, as it seems that messages get lost.

Here again are my permissions. You can see all the suggested permisisons have been assigned but the problem still persists:
Mike-E-angelo 631 Reputation points

2026-02-28T19:51:57.32+00:00

Hi @Shree Hima Bindu Maganti it appears the tag did not make it for my previous post, and tagging you again here just in case. Thank you again for your assistance.
Shree Hima Bindu Maganti 6,890 Reputation points Microsoft External Staff Moderator

2026-03-02T06:17:26.4266667+00:00

Hi @Mike-E-angelo
Thank you for your patience.

Based on the backend logs, the failure is occurring specifically on the Key Vault secret write operation (Microsoft.KeyVault/vaults/secrets/setSecret/action). The caller identified in the error is the AzureAppService service principal (App ID: f3c21649-0979-4721-ac85-b0216b2cf413), and the operation is being denied with a “Forbidden” response.

Although the Key Vault Certificates Officer role allows certificate management actions, the renewal workflow also requires permission to write the certificate as a secret in Key Vault. The error confirms that the setSecret data action is currently not authorized.

Since the Key Vault Secrets Officer role includes Microsoft.KeyVault/vaults/secrets/* dataActions, please ensure:
https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles/security#key-vault-certificates-officer

The role is assigned at the Key Vault scope (not subscription or resource group level mismatch).

The assignment has fully propagated (please allow 10–15 minutes and retry).

The Key Vault is configured to use Azure RBAC (not Access Policies).

There are no deny assignments applied to the vault.

Once verified, please retry the Sync operation and let us know the result.

Let me know if you have any further assistances needed.
Mike-E-angelo 631 Reputation points

2026-03-02T08:39:08.79+00:00

Hi @Shree Hima Bindu Maganti I have shared a screenshot of the exact RBAC permissions requested and as I can tell, they are exactly as prescribed: no deny permissions, RBAC (cannot do this if access policies are applied -- I am not even sure if this is possible anymore as access policies have been phased out?), waited A DAY and tried again (been trying it every day), Key Vault scope (not subscription) and as you can see in your logs the issue still persists. Please further advise on what appears to be a very obvious bug with your software.

Additionally, when looking at my RBAC permissions today I see the following:

The permissions that I applied at your direction are now missing? Please tell me what has transpired here as I have not done any further modifications since the last time you provided direction. Did your team make modifications to the account without the customer's awareness or communication? I hope you can understand the concern.

Thank you for your continued assistance.
Shree Hima Bindu Maganti 6,890 Reputation points Microsoft External Staff Moderator

2026-03-03T18:00:23.22+00:00

Hi @Mike-E-angelo
Thank you for your patience.

Based on the latest backend validation, the service principal f3c21649-0979-4721-ac85-b0216b2cf413 must have the Key Vault Secrets Officer role assigned at the Key Vault scope. The renewal workflow is currently failing on the Microsoft.KeyVault/vaults/secrets/setSecret/action operation, which specifically requires secret-level write permissions.

Regarding the RBAC entries appearing as “Unknown,” this can sometimes occur due to how the Azure portal resolves identities through Microsoft Graph. In certain cases, this is a display resolution issue rather than an actual removal of permissions. To confirm the effective assignments, we recommend validating via Azure CLI (az role assignment list) or refreshing the portal session.

Please ensure that the Key Vault Secrets Officer role is assigned at the correct Key Vault scope, allow sufficient time for RBAC propagation, and then retry the Sync operation.

Kindly let us know once this is completed so we can validate the result from our side.
Mike-E-angelo 631 Reputation points

2026-03-03T18:16:58.0566667+00:00

Hi @Shree Hima Bindu Maganti thank you for your reply.

Based on the latest backend validation, the service principal f3c21649-0979-4721-ac85-b0216b2cf413 must have the Key Vault Secrets Officer role assigned at the Key Vault scope

As I showed you in a previous screenshot I had this permission applied, please confirm.

In certain cases, this is a display resolution issue rather than an actual removal of permissions

OK but I hope you can understand the overall sense that the quality of experience and software here doesn't feel exactly high. I now have nearly a dozen entries that did not exist before contacting your service, and now they appear to still be intact. I hope you can understand the concern, and that it now seems we are fighting two problems now instead of one.

Please ensure that the Key Vault Secrets Officer role is assigned at the correct Key Vault scope, allow sufficient time for RBAC propagation, and then retry the Sync operation.

Please reference the Assignment ID 094873d1-d1bb-43fb-94f9-52abfaebc5a6 you can see it was made on 2/28 and adheres to your previous direction:

The Key Vault Reader role does not grant secret or certificate write permissions. Roles such as: Key Vault Certificates Officer Key Vault Secrets Officer Key Vault Administrator are required for managing certificates and secrets.

Please confirm that I have followed your direction as specified above.
Mike-E-angelo 631 Reputation points

2026-03-03T18:30:59.5266667+00:00

Hi @Shree Hima Bindu Maganti Thank you for your patience. I re-read your previous post and I apologize, but see that you did reference Key Vault Secrets User but I didn't see any code/script so I missed it. 🤦

I did try this but now get an error:

On the good news front, the Unknowns are gone now:

Thank you for your continued assistance.
Shree Hima Bindu Maganti 6,890 Reputation points Microsoft External Staff Moderator

2026-03-03T18:51:36.0133333+00:00

Hi @Mike-E-angelo
Thank you for your continued cooperation.

To help us further isolate the issue, could you please attempt the Sync operation once more and collect a HAR trace while performing the action? This will allow us to capture the exact network request and backend response associated with the failure.

To collect the HAR file:

Open the Azure Portal in your browser.

Press F12 to open Developer Tools.

Navigate to the Network tab.

Click Clear to remove previous entries.

Click Sync in the App Service Certificate blade.

Once the failure appears, right-click inside the Network tab and select Save all as HAR with content.

Kindly share the HAR file with us for analysis.

This will help us validate the exact API response and determine the next troubleshooting steps more precisely.

Thank you again for your patience and cooperation.
Shree Hima Bindu Maganti 6,890 Reputation points Microsoft External Staff Moderator

2026-03-03T19:50:28.34+00:00

Hi @Mike-E-angelo
Thank you for your patience.

Based on the latest backend validation, the permissions are correctly configured and the App Service Certificate has successfully synchronized with the associated Key Vault. The Key Vault sync status shows Succeeded, confirming that the renewed certificate has been properly written to Key Vault.

Thank you again for your continued cooperation.
Mike-E-angelo 631 Reputation points

2026-03-03T20:13:26.6533333+00:00

Hi @Shree Hima Bindu Maganti thank you for your continued assistance. Unfortunately that is not what I see in the portal:

The error still occurs when I synchronize:

I tried to share the HAR file in the private chat, but it is not supported. Edit: I was able to rename the file type and send it to you. 👍
Shree Hima Bindu Maganti 6,890 Reputation points Microsoft External Staff Moderator

2026-03-04T19:39:49.31+00:00
Hi @Mike-E-angelo
Thank you for your patience.

The sync failure is occurring because the Azure App Service service principal (abfa0a7c-a6b6-4736-8310-5855508787cd) does not have permission to read the certificate secret from Key Vault. The backend logs show a 403 Forbidden for the action Microsoft.KeyVault/vaults/secrets/getSecret/action.

This can be resolved by assigning the Key Vault Certificate User role to the Azure App Service principal using the command below:

az role assignment create --role "Key Vault Certificate User" \ --assignee "abfa0a7c-a6b6-4736-8310-5855508787cd" \ --scope /subscriptions/{subscriptionid}/resourcegroups/{resource-group-name}/providers/Microsoft.KeyVault/vaults/{key-vault-name}

This role provides the required permission to read the certificate secret during the sync operation. As documented in Microsoft’s built-in role definition, the Key Vault Certificate User role includes the required data actions such as:

Microsoft.KeyVault/vaults/certificates/read Microsoft.KeyVault/vaults/secrets/getSecret/action Microsoft.KeyVault/vaults/secrets/readMetadata/action Microsoft.KeyVault/vaults/keys/read

Reference: https://docs.azure.cn/en-us/role-based-access-control/built-in-roles/security#key-vault-certificate-user

Once this role is applied, the App Service should be able to retrieve the certificate secret from Key Vault and the sync operation should complete successfully.

1 answer

Your answer

Golla Venkata Pavani 2,340 Reputation points Microsoft External Staff Moderator

2026-02-27T21:25:08.04+00:00

Hi @Mike-E-angelo ,

Thank you for reaching us regarding the issue.

From the backened logs and the screenshot now shared, you can see that the account that was asked to be added has only "Key Vault Reader" role and not "Key Vault Certificates Officer".

If using RBAC instead of access policies, ensure equivalent roles are assigned at the vault scope, for example via:

az role assignment create --role "Key Vault Certificates Officer" --assignee "f3c21649-0979-4721-ac85-b0216b2cf413" --scope /subscriptions/{subscriptionid}/resourcegroups/{resource-group-name}/providers/Microsoft.KeyVault/vaults/{key-vault-name}

This explains why the Sync operation reports successful it validates the linkage metadata but the backend operation that reads or updates the secret fails silently due to insufficient secret permissions. As documented by Microsoft, the CertificateRegistration service principal must have secret-level access to the Key Vault for renewal to complete properly.

Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.
Mike-E-angelo 631 Reputation points

2026-02-28T08:51:05.5533333+00:00

Hi @Golla Venkata Pavani thank you for your reply.

As documented by Microsoft, the CertificateRegistration service principal must have secret-level access to the Key Vault for renewal to complete properly.

Can you please provide the exact location and URL for this documentation? As you can see from the history of the previous thread, Key Vault Certificates Officer was never recommended by either of your agents. Indeed, via Private Message (which is no longer available because it was ... removed? please explain) @Shree Hima Bindu Maganti suggested Key Vault Secrets User and this did not work, either.

Before I continue to add even more permissions that may or may not work, can I please get an explaination from you for why ticket #2602190040001844 was closed without customer confirmation? I hope you can understand the concern. Thank you for your assistance.
Shree Hima Bindu Maganti 6,890 Reputation points Microsoft External Staff Moderator

2026-02-28T13:50:55.62+00:00

Hi @Mike-E-angelo
Apology for your inconveniences
Thank you for your patience. Based on backend validation, the issue appears to be permission-related. From the screenshot shared, the relevant service principal currently has the Key Vault Reader role, which only provides read access. It does not allow certificate or secret write operations required for renewal and synchronization.

For App Service Certificate renewal to complete properly, the Microsoft.Azure.CertificateRegistration service principal must have certificate-level permissions in Key Vault.

For your reference: https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-guide?tabs=azure-cli

For your reference: https://learn.microsoft.com/en-us/azure/key-vault/general/about-keys-secrets-certificates#access-policies

The Key Vault Reader role does not grant secret or certificate write permissions. Roles such as:

Key Vault Certificates Officer

Key Vault Secrets Officer

Key Vault Administrator

are required for managing certificates and secrets.

Please assign the following role to the Microsoft.Azure.CertificateRegistration service principal:

az role assignment create \ --role "Key Vault Certificates Officer" \ --assignee "f3c21649-0979-4721-ac85-b0216b2cf413" \ --scope /subscriptions/{subscriptionid}/resourcegroups/{resource-group-name}/providers/Microsoft.KeyVault/vaults/{key-vault-name}

Alternatively, this can be done in the Azure Portal:

Key Vault → Access control (IAM) → Add role assignment → Select Key Vault Certificates Officer → Assign to Microsoft.Azure.CertificateRegistration

After assigning the role, please retry the Sync operation.
Let me know if you have any further assisstences needed.
Mike-E-angelo 631 Reputation points

2026-02-28T14:30:17.6033333+00:00

Hi, thank you for your reply, and there is certainly something amiss here, as I replied to your private message in the other thread showing you the permissions, and the problem still persisted. Closing a ticket is one thing, but closing a private message as a backup communication seems even worse as it deletes previous history and important details. If it's ok with you, let's please no longer use private messages, as it seems that messages get lost.

Here again are my permissions. You can see all the suggested permisisons have been assigned but the problem still persists:
Mike-E-angelo 631 Reputation points

2026-02-28T19:51:57.32+00:00

Hi @Shree Hima Bindu Maganti it appears the tag did not make it for my previous post, and tagging you again here just in case. Thank you again for your assistance.
Shree Hima Bindu Maganti 6,890 Reputation points Microsoft External Staff Moderator

2026-03-02T06:17:26.4266667+00:00

Hi @Mike-E-angelo
Thank you for your patience.

Based on the backend logs, the failure is occurring specifically on the Key Vault secret write operation (Microsoft.KeyVault/vaults/secrets/setSecret/action). The caller identified in the error is the AzureAppService service principal (App ID: f3c21649-0979-4721-ac85-b0216b2cf413), and the operation is being denied with a “Forbidden” response.

Although the Key Vault Certificates Officer role allows certificate management actions, the renewal workflow also requires permission to write the certificate as a secret in Key Vault. The error confirms that the setSecret data action is currently not authorized.

Since the Key Vault Secrets Officer role includes Microsoft.KeyVault/vaults/secrets/* dataActions, please ensure:
https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles/security#key-vault-certificates-officer

The role is assigned at the Key Vault scope (not subscription or resource group level mismatch).

The assignment has fully propagated (please allow 10–15 minutes and retry).

The Key Vault is configured to use Azure RBAC (not Access Policies).

There are no deny assignments applied to the vault.

Once verified, please retry the Sync operation and let us know the result.

Let me know if you have any further assistances needed.
Mike-E-angelo 631 Reputation points

2026-03-02T08:39:08.79+00:00

Hi @Shree Hima Bindu Maganti I have shared a screenshot of the exact RBAC permissions requested and as I can tell, they are exactly as prescribed: no deny permissions, RBAC (cannot do this if access policies are applied -- I am not even sure if this is possible anymore as access policies have been phased out?), waited A DAY and tried again (been trying it every day), Key Vault scope (not subscription) and as you can see in your logs the issue still persists. Please further advise on what appears to be a very obvious bug with your software.

Additionally, when looking at my RBAC permissions today I see the following:

The permissions that I applied at your direction are now missing? Please tell me what has transpired here as I have not done any further modifications since the last time you provided direction. Did your team make modifications to the account without the customer's awareness or communication? I hope you can understand the concern.

Thank you for your continued assistance.
Shree Hima Bindu Maganti 6,890 Reputation points Microsoft External Staff Moderator

2026-03-03T18:00:23.22+00:00

Hi @Mike-E-angelo
Thank you for your patience.

Based on the latest backend validation, the service principal f3c21649-0979-4721-ac85-b0216b2cf413 must have the Key Vault Secrets Officer role assigned at the Key Vault scope. The renewal workflow is currently failing on the Microsoft.KeyVault/vaults/secrets/setSecret/action operation, which specifically requires secret-level write permissions.

Regarding the RBAC entries appearing as “Unknown,” this can sometimes occur due to how the Azure portal resolves identities through Microsoft Graph. In certain cases, this is a display resolution issue rather than an actual removal of permissions. To confirm the effective assignments, we recommend validating via Azure CLI (az role assignment list) or refreshing the portal session.

Please ensure that the Key Vault Secrets Officer role is assigned at the correct Key Vault scope, allow sufficient time for RBAC propagation, and then retry the Sync operation.

Kindly let us know once this is completed so we can validate the result from our side.
Mike-E-angelo 631 Reputation points

2026-03-03T18:16:58.0566667+00:00

Hi @Shree Hima Bindu Maganti thank you for your reply.

Based on the latest backend validation, the service principal f3c21649-0979-4721-ac85-b0216b2cf413 must have the Key Vault Secrets Officer role assigned at the Key Vault scope

As I showed you in a previous screenshot I had this permission applied, please confirm.

In certain cases, this is a display resolution issue rather than an actual removal of permissions

OK but I hope you can understand the overall sense that the quality of experience and software here doesn't feel exactly high. I now have nearly a dozen entries that did not exist before contacting your service, and now they appear to still be intact. I hope you can understand the concern, and that it now seems we are fighting two problems now instead of one.

Please ensure that the Key Vault Secrets Officer role is assigned at the correct Key Vault scope, allow sufficient time for RBAC propagation, and then retry the Sync operation.

Please reference the Assignment ID 094873d1-d1bb-43fb-94f9-52abfaebc5a6 you can see it was made on 2/28 and adheres to your previous direction:

The Key Vault Reader role does not grant secret or certificate write permissions. Roles such as: Key Vault Certificates Officer Key Vault Secrets Officer Key Vault Administrator are required for managing certificates and secrets.

Please confirm that I have followed your direction as specified above.
Mike-E-angelo 631 Reputation points

2026-03-03T18:30:59.5266667+00:00

Hi @Shree Hima Bindu Maganti Thank you for your patience. I re-read your previous post and I apologize, but see that you did reference Key Vault Secrets User but I didn't see any code/script so I missed it. 🤦

I did try this but now get an error:

On the good news front, the Unknowns are gone now:

Thank you for your continued assistance.
Shree Hima Bindu Maganti 6,890 Reputation points Microsoft External Staff Moderator

2026-03-03T18:51:36.0133333+00:00

Hi @Mike-E-angelo
Thank you for your continued cooperation.

To help us further isolate the issue, could you please attempt the Sync operation once more and collect a HAR trace while performing the action? This will allow us to capture the exact network request and backend response associated with the failure.

To collect the HAR file:

Open the Azure Portal in your browser.

Press F12 to open Developer Tools.

Navigate to the Network tab.

Click Clear to remove previous entries.

Click Sync in the App Service Certificate blade.

Once the failure appears, right-click inside the Network tab and select Save all as HAR with content.

Kindly share the HAR file with us for analysis.

This will help us validate the exact API response and determine the next troubleshooting steps more precisely.

Thank you again for your patience and cooperation.
Shree Hima Bindu Maganti 6,890 Reputation points Microsoft External Staff Moderator

2026-03-03T19:50:28.34+00:00

Hi @Mike-E-angelo
Thank you for your patience.

Based on the latest backend validation, the permissions are correctly configured and the App Service Certificate has successfully synchronized with the associated Key Vault. The Key Vault sync status shows Succeeded, confirming that the renewed certificate has been properly written to Key Vault.

Thank you again for your continued cooperation.
Mike-E-angelo 631 Reputation points

2026-03-03T20:13:26.6533333+00:00

Hi @Shree Hima Bindu Maganti thank you for your continued assistance. Unfortunately that is not what I see in the portal:

The error still occurs when I synchronize:

I tried to share the HAR file in the private chat, but it is not supported. Edit: I was able to rename the file type and send it to you. 👍
Shree Hima Bindu Maganti 6,890 Reputation points Microsoft External Staff Moderator

2026-03-04T19:39:49.31+00:00

Hi @Mike-E-angelo
Thank you for your patience.

The sync failure is occurring because the Azure App Service service principal (abfa0a7c-a6b6-4736-8310-5855508787cd) does not have permission to read the certificate secret from Key Vault. The backend logs show a 403 Forbidden for the action Microsoft.KeyVault/vaults/secrets/getSecret/action.

This can be resolved by assigning the Key Vault Certificate User role to the Azure App Service principal using the command below:

az role assignment create --role "Key Vault Certificate User" \ --assignee "abfa0a7c-a6b6-4736-8310-5855508787cd" \ --scope /subscriptions/{subscriptionid}/resourcegroups/{resource-group-name}/providers/Microsoft.KeyVault/vaults/{key-vault-name}

This role provides the required permission to read the certificate secret during the sync operation. As documented in Microsoft’s built-in role definition, the Key Vault Certificate User role includes the required data actions such as:

Microsoft.KeyVault/vaults/certificates/read Microsoft.KeyVault/vaults/secrets/getSecret/action Microsoft.KeyVault/vaults/secrets/readMetadata/action Microsoft.KeyVault/vaults/keys/read

Reference: https://docs.azure.cn/en-us/role-based-access-control/built-in-roles/security#key-vault-certificate-user

Once this role is applied, the App Service should be able to retrieve the certificate secret from Key Vault and the sync operation should complete successfully.

Answer 1

Answer: Hi @Shree Hima Bindu Maganti, thank you for your suggestion, which seemed to have done the trick.

So there are two permissions, it seems, and I have yet to see a URL/resource/web page that clearly describes the necessary permissions as expected by your system, nor are there easy-to-read/understand scripts displayed to the user at any time to remedy the situation.

Rather, I have had to open a "ticket" here and wait over six weeks as several agents attempted to provide guidance, but none were able to grant the permissions needed to fix the issue.

Additionally, a support ticket was opened and then closed after several days, with no confirmation from the customer.

Then, once I had someone with visibility into my account, incorrect permissions (Key Vault Certificates Officer) were suggested as a remedy again, but it continued to fail.

All the while, a message was displayed to the user that the operation had successfully completed, even though this was not the case. This seems like a very obvious bug in your system. At no point would I ever consider displaying a "successful" message to users of any of the applications I manage when an exception is thrown in the background, preventing the operation from completing successfully. This is very basic software engineering 101 stuff, and it's more than impressive that we have spent more than six weeks addressing an issue whose core cause was a permissions issue.

Why is the portal simply not showing the error message to the user, along with the exact details of the permissions needed? Why is there no page that shows exactly which permissions are needed? Recall that I screencaptured the permissions several times as shown, and they seemed to match the permissions provided by agents.

Why do I have to spend 6 weeks fixing something that should be clearly displayed to the user via the UI? One of Azure Portal's great mysteries, never to be solved, I guess.

Share via

App Service Certificate Out of Sync and DOES NOT SYNC Take II

1 answer

Your answer