I am trying to update APIM custom domains with new certificates from the KeyVault. But it fails with the message "Failed to update API management service hostnames" with some CorrelationID.
I tried to delete the domain from the custom domain list, still the same here. Has anyone faced similar issue? Any leads will be helpful.
Failed to update API management service hostnames
This error usually occurs when you try to use an Azure Key Vault certificate to add a custom domain to your API Management service.
This is because the API Management service does not have permission to access the key vault for the custom domain you're trying to use.
You can refer this MSFT documentation, where one of the work around for this type of error is given.
I fixed the issue.
So basically, I had two custom domains for which the certificates were expired. I was trying to update one of them with new certificate. But it failed all the time.
So the solution is delete all the custom domains that have expired certificates, save them and add the domains again with new certificates.
Related
I created a Private Link connection between an Azure VM and a CosmosDB MongoDB Account.
In order to clear out the need for token authentication and taking into account the best practices, I assigned a custom role to the Virtual Machine which has permissions to read and write to CosmosDB.
Now I am trying to connect the VM to CosmosDB using Python (pymongo) without any type of authentication on the uri string. Nevertheless, I am having auth errors and I cannot seem to find any relevant example or information regarding this matter.
Is there any way to achieve this? If not, what are my alternatives? Must I use tokens even with a private link?
#Anupam Chand Thank you for your response in the comment section.
Yes, We Can avoid tokens by creating a service principal for your VM and then assign the appropriate RBAC to the service principal. At present .NET , Java and JavaScript SDKs are currently supported. Python SDK not yet available.
I am thinking of buying a wildcard certificate for my domain. In the near future, we plan to move the app and app service and databases to another Azure subscription. I would like to know if it is possible to move the wildcard certificate to the new subscription?
According to the documentation, it should be able to meet your requirements, but there are some things that need attention. Move guidance for App Service resources
You need to try,if can't. You will need to delete the SSL bindings, and move a certificate bound to the new website.
To add to this you can refer to the following Azure documentation: Purchase, Store and Assign an SSL Certificate for your custom domain for details on this topic. If you plan to move App Service resources to a new resource group or subscription, there are a few limitations to be aware of, see App Service limitations.
Also, you can migrate your App Service Certificate within the Azure portal. You can also export it as a PFX file for use in another subscription. See this blog post for more information.
The certificate that came configured with our Azure API management endpoint expired today (apparently it was only valid for one year). How do we renew it?
We thought that the point of using the default API management certificate provided by MS meant we did not have to manually worry about renewing it. But this appears not to be the case.
expired certificate message
I believe this is a Microsoft/Azure issue, as Azure manages this certificate. I would recommend creating a ticket in the Azure portal to report it.
Team,
I have recently migrated my azure classic portal resources to CSP subscription. I have successfully converted my azure cloud service to azure app website in the CSP subscription. But there is one thing i am not able connect. Its the third party API When we had the cloud service we had a .pfx uploaded to azure and in the code we use to create a uri which consists of the certifcate key + certificate secret key.
The certificate key is got directly from web.config. But the certificate secret key is got from EncryptedSettings.Appsettings("SecretKeyName").
This is basically got from the encrypted app setting done earlier by
https://eren.ws/2014/02/04/encrypting-the-web-config-file-of-an-azure-cloud-service/
But i am not sure what way should we implement on Azure website.
I have tried implementing the same but unfortunately it seems the secret key retrieval technique for cloud service is not the same as in the azure web app service.
When i debug the azure web site i can see that it gives the error as.
Failed to decrypt using provider ‘CustomProvider’. Error message from the provider: Value cannot be null.
Parameter name: keyObject
Can anyone please guide me ?
Rather than storing secrets in your config, you may wish instead to store them Azure KeyVault (which also gives you secret management capabilities etc) and then load the secrets at runtime.
KeyVault documentation:
https://learn.microsoft.com/en-us/azure/key-vault/
Specifically how to use keyvault with azure websites:
https://learn.microsoft.com/en-us/azure/key-vault/key-vault-use-from-web-application
And these days, don't bother with manual authentication to use keyvault, instead use "Managed Service Identity", here's a tutorial:
https://azure.microsoft.com/en-gb/resources/samples/app-service-msi-keyvault-dotnet/
Interestingly the second tutorial does mention specifically using certificates for the purposes of authentication (against keyvault), you may wish to use this technique for yourself as a simplified way to get direct access to your certificate.
I'm doing some testing with a new Cloud Service and for some reason in my certificates I'm getting a bunch of these entries
DC=Windows Azure Service Management for Extensions
All have different thumbprints. Doesn't seem to be affecting anything.. but annoying to have in the list.
What are they? How do I stop them from auto populating?
The things you could do through Azure Management Portal (like creating Cloud Services etc.) can essentially be done through Azure Service Management API. Management certificates are one way of authenticating your Service Management API requests: http://msdn.microsoft.com/en-us/library/azure/ee460782.aspx#bk_cert.
There are many reasons that these certificates are created automatically. Some of them are:
Whenever you download a publish setting file, a new management certificate is created.
If you try to connect to your cloud service VM via RDP through portal, if you don't pay attention, a new certificate is created for RDP. I'm not 100% sure but same thing happens when you update Azure Diagnostics as diagnostics is again an extension.