Moving Microsoft.Web/certificates between Key Vaults

[chwarr]

I need to move a certificate that I use with an App Service app from one Key Vault to another (in the same subscription).

The certificate is deployed using:

param keyVaultCerts array
param resourceTags object
param serverFarmId string

var delimiters = [
  '/'
]

// split uri to retrieve keyvault secret name
resource certificates 'Microsoft.Web/certificates@2021-02-01' = [for config in keyVaultCerts: {
  name: '${split(config.secretUris,delimiters)[4]}'
  location: resourceGroup().location
  tags: resourceTags
  properties: {
    keyVaultId: config.keyVaultId
    keyVaultSecretName: '${split(config.secretUris,delimiters)[4]}'
    serverFarmId: serverFarmId
  }
}]

output response array = [for (config, i) in keyVaultCerts: {
  name: certificates[i].name
  resourceId: certificates[i].id
  thumbprint: certificates[i].properties.thumbprint
}]

This deployment fails wit the error

certificateEnvelope.Properties.KeyVaultId is invalid. Certificate cannot be updated from one vault to another. Delete and recreate the certificate

Is there a recommended way to solve this with Bicep?

[brwilkinson]

How was the certificate created/generated? i.e. was it an App Service Certificate?

or was it imported (manually) into the keyvault?

• There is no specific way to copy a certificate in Bicep that I am aware of.

I do sync keyvault secrets and certificates with this script.

https://github.com/brwilkinson/AzureDeploymentFramework/blob/main/ADF/1-prereqs/3-Start-AzureKVSync.ps1

 .\3-Start-AzureKVSync.ps1 -primaryKVName ACU1-BRW-AOA-P0-kvVLT01 -SecondaryKVName AWU1-BRW-AOA-P0-kvVLT01

I would suggest to sync or copy the cert over to the new keyvault, then register a new web certificate, based on the new values.

Adding this incase it is helpful:
https://github.com/brwilkinson/AzureDeploymentFramework/blob/main/ADF/bicep/x.appService.bicep

[brwilkinson]

Can confirm App Service will not allow adding in a cert with the same/duplicate Thumbprint.... which I think makes sense since that is how the binding works i.e. based on the thumbprint.

Another certificate exists with same thumbprint 48B8F2B8C7DE8115804B74D8CBB4488C53492E5F at location Central US in the Resource Group ACU1-BRW-AOA-RG-T5

As soon as I deleted the current certificate (from the first KV) and redeployed it immediately pulled in the cert from the other keyvault and I also tested binding to that new cert, and it works fine, as expected in that same deployment.

• Based on this I am not too sure without thinking it over some more how you may handle a migration, unless you flip to a managed cert temporarily, then flip back, however if it's a microsoft domain? I am not sure if that is possible. So I think you would need to generate a new cert with a new thumbprint, if you cannot afford some downtime, at least this is my initial impression.

Example below of the Cert from the KV, then the Managed Cert, with different Thumbprints, I can easily flip between them both, simply by deploying and referencing the Thumbprint on the binding.

[chwarr]

For my case, TLS/domain name bindings don't come into play. These certificates are used for something else.

As far as I understand, when I create a Microsoft.Web/certificates@2021-02-01 resource, App Service will make that certificate available in the local certificate store. (Yes, App Service has been granted access to both the Key Vaults.) App Service will then monitor the Key Vault for changes and update the certificate in the local machine's certificate store as needed. These appear on the portal under "Private Key Certificates". My app has the setting WEBSITE_LOAD_CERTIFICATES set to * so that they all are loaded into CurrentUser\My certificate store.

I'm coming from a Pulumi background. In Pulumi, I could just set deleteBeforeReplace: true and the old, now stale Microsoft.Web/certificates@2021-02-01 would be deleted before the new one was created pointing at the new Key Vault during the pulumi up process.

With my current understanding of Bicep, I'm stuck figuring out how to pull off this switcharoo.

Options I see right now:

1. Manually delete these certificates from App Service and deploy pointing at the new Key Vault.
2. Do an intermediate deployment without any of these certificates so that Bicep will delete them. Then deploy pointing at the new Key Vault.

[brwilkinson]

Currently ARM/Bicep doesn't have a model that is very workable around 'complete' deployment models to delete or cleanup resources. There are some private previews on 'Deployment Stacks' that are designed to handle lifecycle related issues like this, however it's not currently available.

• Looks like we both sent the message at the same time.

If options 1. an feasible for you, then the overall deployment takes less than 1 minute, I would just delete it and redeploy...

• I would test pulling in an alternate certificate from that keyvault with a different thumbprint first, so that you know your RBAC is set correctly prior to deleting the current certificate. Other than that, it should be straightforward.

[chwarr]

Agreed a moment of downtime to manually clean up the stale Microsoft.Web/certificates@2021-02-01 instances is probably the best trade-off for my situation.

I would test pulling in an alternate certificate from that keyvault with a different thumbprint first, so that you know your RBAC is set correctly prior to deleting the current certificate. Other than that, it should be straightforward.

That's a very good idea. Thanks!

[brwilkinson]

I'll mark this as answered, if you make any further discoveries on the process, please share back to the converation.

[santo2]

I'm sorry but if I read it correct, there is no "migration" way of doing this? I need to KILL a running website on PRODUCTION to be able to do this?