How do you trigger Azure CDN to read the latest version of custom certificate from Key Store without downtime?
My CDN-setup is working ok, but given Let's Encrypt, the certificate is short lived and requires automation for updates. Doing az keyvault certificate import is trivial enough on Azure CLI to update the certificate into Key Vault, but what next? How do you tell Azure CDN to start using the new version of the cert?
Failed attempts
Waiting for couple hours. Nothing happened.
Running az cdn custom-domain enable-https on a domain having the HTTPS already enabled. Result: an internal misconfiguration and couple hours of downtime to first disable the custom domain and then enable it. Certificate was updated, though.
From Azure Portal
Azure Portal tooltip on custom domain certificate version says "Select the version of the certificate you want to use. By default we'll use the latest version." That is true when creating the endpoint, but how do you start using the latest version? The latest version is already selected from dropdown, but I did select the previous version and select the latest version. Doing that enabled "Save".
Saving the form resulted in no-downtime update of the certificate. Nice, but given automation and scripting, not really the way to go.
Things which might do the trick, but I haven't tested yet
Applying ARM-template of the CDN-setup
Powershell Az.Cdn has Start-AzCdnEndpoint/Stop-AzCdnEndpoint cmdlets. Maybe helpful, but 100% guarantee to generate downtime.
Is there anything I can try on next update cycle?
As of 2021-04-05, Azure CDN can be told to use the "Latest" version of a particular KeyVault certificate. I haven't found any news of this change, but it was added to the documentation with this commit.
In order for the certificate to be automatically rotated to the latest version when a newer version of the certificate is available in your Key Vault, please set the certificate/secret version to 'Latest'. If a specific version is selected, you have to re-select the new version manually for certificate rotation. It takes up to 24 hours for the new version of the certificate/secret to be deployed.
In the portal, this can be done by choosing the "Latest" option in the "Certificate/Secret version" dropdown. With the Azure CLI, this can be done with:
az cdn custom-domain enable-https \
--resource-group "$cdnResourceGroupName" \
--profile-name "$cdnProfileName" \
--endpoint-name "$cdnEndpointName" \
--name "$cdnCustomDomainName" \
--user-cert-subscription-id "$subscriptionId" \
--user-cert-group-name "$keyVaultResourceGroupName" \
--user-cert-vault-name "$keyVaultName" \
--user-cert-secret-name "$secretName" \
--user-cert-protocol-type 'sni'
Notice that this command does not set the --user-cert-secret-version parameter, which is how you select the "Latest" functionality.
For anyone who wants to do it manually, the old answer of doing this manually is below.
Running az cdn custom-domain enable-https on a domain having the HTTPS already enabled. Result: an internal misconfiguration and couple hours of downtime to first disable the custom domain and then enable it.
As of 2021-04-05, this can be done with the Azure CLI with:
az cdn custom-domain enable-https \
--resource-group "$cdnResourceGroupName" \
--profile-name "$cdnProfileName" \
--endpoint-name "$cdnEndpointName" \
--name "$cdnCustomDomainName" \
--user-cert-subscription-id "$subscriptionId" \
--user-cert-group-name "$keyVaultResourceGroupName" \
--user-cert-vault-name "$keyVaultName" \
--user-cert-secret-name "$secretName" \
--user-cert-secret-version "$secretVersion" \
--user-cert-protocol-type 'sni'
(When this answer was originally written in 2019 May, the Azure CLI documented a --custom-domain-https-parameters parameter that implied it could be used for this purpose. If the parameter was not supplied, the CLI would run the CDN-managed cert workflow (cert issued by DigiCert). However, it was never properly documented how to actually use the parameter. As of 2021 March, the parameter was removed from the CLI again. Finally, as of 2021 April, the --user-cert-* parameters have been added.)
The equivalent feature was added in 2019 March to the .Net SDK,. So the Nuget package should allow you to use user-managed certs.
As of 2021 April, Azure PowerShell's Enable-AzCdnCustomDomainHttps commandlet still does not support user-managed certs, only CDN-managed certs.
Or you can use the REST API directly as documented here. Make a POST request to https://management.azure.com/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Cdn/profiles/$cdnProfileName/endpoints/$cdnEndpointName/customDomains/$cdnCustomDomainName/enableCustomHttps?api-version=2018-04-02 with an application/json body that looks like
{
"certificateSource": "AzureKeyVault",
"certificateSourceParameters": {
"#odata.type": "#Microsoft.Azure.Cdn.Models.KeyVaultCertificateSourceParameters",
"deleteRule": "NoAction",
"resourceGroupName": "$resourceGroupName",
"secretName": "$secretName",
"secretVersion": "$secretVersion",
"subscriptionId": "$subscriptionId",
"updateRule": "NoAction",
"vaultName": "$keyVaultName"
},
"protocolType": "ServerNameIndication"
}
$resourceGroupName and $keyVaultName identify the KeyVault. $secretName and $secretVersion identify the certificate. (Don't be confused if the Portal doesn't show any secrets in your KeyVault; a KeyVault certificate with a private key is implicitly a KeyVault secret with the same name and version.)
This API endpoint follows standard REST semantics, in that it returns HTTP 202 Accepted since it's a long-running async operation. It'll set the Location header in the response, and you should GET that URL repeatedly till it resolves to a success or failure status code.
Note that the portal also uses the REST API, so you can always derive this from just doing the steps in the portal UI and inspecting the network requests in your browser's developer tools. You will need to get your own oauth2 token, though (by creating an SP).
Aside: To save people the time it took me to discover this when trying to do this for my own domain, do not be fooled by the documentation or the example in the Azure Rest API specs repo. They imply the API version 2017-10-12 supports customHttpsParameters, but in fact only 2018-04-02 and newer support it. If you use 2017-10-12 then the parameter is silently ignored, and it will try to use the Digicert automatic cert workflow.
As suggested by #Arnavion, Azure CDN Custom Domain REST API call can be used to trigger the update of the certificate used by an existing custom domain in Azure CDN. The suggested API docs are at https://learn.microsoft.com/en-us/rest/api/cdn/customdomains/enablecustomhttps. When combining above example with API reference information, it is possible to craft a suitable request with PowerShell 6 Invoke-RestMethod. On success, CDN will start updating the certificate from Key Vault to endpoints in a few minutes.
There is no trickery involved in the operation. All that is needed is to gather all required five parameters for API-required UserManagedHttpsParameters to indicate the exact custom domain in the CDN and pinpoint the X.509 certificate at Key Vault. What is also needed is to combine the parameters with a valid bearer token and then make the mentioned API-call to inform CDN to pick up the new certificate from Key Vault and deploy it to all CDN endpoints.
My script doing all this is available at https://gist.github.com/HQJaTu/c5695626ba51c6194845fa60913e911b
How you get the new certificate into Key Vault is an another discussion and my script won't address that. However, uploading a new version of a certificate is much easier than triggering the CDN-update.
At the moment documentation for Azure CLI still doesn't give answer how to do it.
I have written some python script to do it as a part the of acme.sh renew-hook.
Mainly it works for apex custom domain but you can use it with subdomains.
You can find it on github -> https://github.com/przemika/azure-byoc-for-custom-domain
Related
I would like to add a custom domain that is managed by AWS to my Azure Static Web App. Microsoft documentation shows how to add one if the DNS is managed by Azure itself. Sadly, I cannot find anything for my use case. To be more clear, the function I'd like to use with Azure command line is shown in this picture.
I have tried az staticwebapp hostname set --name FOO --hostname BAR.com which doesn't work.
I suppose you have already configured CNAME/TXT/ALIAS record with your DNS provider.
You may use --no-wait option to not wait for validation or use --validation-method "dns-txt-token" or "cname-delegation"
I would also suggest to verify your CNAME record, as often domain field must be filled with subdomain, not regular/naked domain.
Please also check if you are using the latest version of az cli.
You may check version using command az version
https://learn.microsoft.com/en-us/cli/azure/staticwebapp/hostname?view=azure-cli-latest#az-staticwebapp-hostname-set-examples
Please let me know how to backup Azure WAF Resource Configuration/settings. I am not able find anything related to waf backup setting/configuration.
Go to Application Gateway -> Export Template
The template contains all configuration/settings for your WAF
I appreciate this question is a little old now - the answer already given and accepted is technically valid but note that any export of an Application Gateway you do that uses "SSL Certificates" will not include the certificates in the export.
So if you were to try and re-create the Application Gateway from the exported JSON, it will probably not work and may need additional configuration to re-import the SSL certificates referenced by listeners.
For information, you can also use the Export-AzResourceGroup cmdlet to export your App Gateway but this too does not include the SSL certificates.
A fairly recent (end of 2020) addition which alleviates this to some extent is the ability to pass a reference to a Key Vault certificate but this requires a User Assigned Managed Identity to be associated with the Application Gateway which has permissions to access the certificates and secrets (if they had passwords when added to the Key Vault).
Create a user-assigned managed identity - look for Managed Identities in the Azure Portal.
Configure your key vault - this basically means add permissions to the Key Vault for the Managed Identity to be able to manage certificates and read secrets.
Configure the application gateway. Use the Set-AzApplicationGatewayIdentity cmdlet to assign the UA-MI account's ID to the Application Gateway.
The instructions above are abbreviated from this article (which I'll get grief for adding, but I'm not regurgitating documentation here for the sake of it): https://learn.microsoft.com/en-us/azure/application-gateway/key-vault-certs
Remember that I said the key vault integration alleviates the issue to some extent. Using references still doesn't resolve the issue completely as I believe there are still some pieces of secret information omitted from exports which would be needed to fully re-create the Application Gateway in a working state.
I am trying to follow the tutorial for deploying a split-merge service (Azure Elastic Database... tools).
The first complication is that the doc instructs me to create an "Azure Cloud Service." The closest thing to that seems to be "Cloud service (classic)," so that's what I created.
When it came to creating a self-signed cert, I had to translate the parameters for makecert (which is deprecated and no longer seems to be present in any SDKs) to the powershell New-SelfSignedCertificate cmdlet. The relevant params I passed to the cmdlet were:
Subject: CN=*.cloudapp.net
KeySpec: KeyExchange
TextExtension: 2.5.29.37={text}1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2
I finally got the certificate created/exported/uploaded, got the service configuration file completed and created the service. Azure portal reports the web and workers running, but I can't hit the service URL (403 access denied even after prompting me to select my certificate). I confirmed that my certificate thumbprint shows correctly in the various places in the service configuration (DataEncryptionPrimaryCertificateThumbprint, DataEncryptionPrimary, AdditionalTrustedRootCertificationAuthorities, AllowedClientCertificateThumbprints, DataEncryptionPrimaryCertificateThumbprint). My certificate's thumbprint also shows as the thumbprint in configuration under the "Certificates" section as SSL, CA, and DataEncryptionPrimary.
The only thing I can think of that is causing the access denied is something mentioned in this doc, "If you are using self-signed certificates, you will need to disable certificate chain validation." The PowerShell cmdlet that it shows to use to disable chain validation in that case (for an API service; no clue how that differs from my service) fails with InvalidOperation.
Is there some way for me to disable certificate chain validation for my "classic" cloud service? Other suggestions of things to check?
For Application gateway all documentation says to upload pfx certificate but when I go to http settings for backend pool it only allows ".cer" certificate and it wont allow ".pfx" file to be uploaded, error displayed says wrong format ?
m i doing something wrong or somehow Azure has changed functionality but documentation is still not uploaded .
Strangely through this command I am able to upload PFX
az network application-gateway ssl-cert create
Screenshot attached
Update : I am trying to do this for an existing Application Gateway
Update 2 : Strangely when I am creating a gateway Azure shows me option for PFX but I dont know why it become cer if I am trying to do this for an existing one.
Is this one of Microsoft's easter eggs??
It seems you select wrong entrance on Portal.
If you configure Add HTTP setting, you really need a .cer certificate.
More information please refer to this link.
The command az network application-gateway ssl-cert create is used for configure SSL. You could find it on Portal Settings--Listener.
I'm using a Azure Resource Manager(ARM) template to create and update a resource group in a release definition in Visual Studio Team Services(VSTS). I'm using the same template to upload the .pfx certificate to the web app.
For the first deployment the certificate got uploaded perfectly, but from the next deployment the deployment fails with the error "Another certificate exists with same thumbprint ******** at location West US in the Resource Group MyResourceGroup".
I tried recreating the webapp, but to my surprise the deployment fails for the first time itself. Looks like the certificate got uploaded to the resource group.
Is there a way to overwrite the existing .pfx certificate for every deployment.
You do not have to upload certificate for all deployments. The first certificate will become available to all deployments
Certificates are exposed at the resource group level, so deploying the same certificate again will definitely error out.
However, I don't see a reason as to why you need to upload a certificate.
Does your application need to read this certificate? if yes, then there is a different way to do this. See this article:
https://azure.microsoft.com/en-us/blog/using-certificates-in-azure-websites-applications/
Until today I had never encountered this error. I have been able to redeploy my applications, certificates and all, with no issues. I believe in my case that someone had previously manually added the certificate using a different name, possibly through the portal, and then when my pipeline executed it attempted to add the certificate using a different name.
Certificates are child resources of Microsoft.Web under the resource group. There are likely a number of options for resolving but I am going to focus on removing the certificate using Resource Explorer. (I bet that there is a Azure CLI or Azure PowerShell command to do this too.)
In resource explorer, locate the certificates node associated with your resource group using the left hand navigation pane. This will likely be in something like subscriptions -> {subscription name} -> resourceGroups -> {resource group name} -> providers -> Microsoft.Web -> certificates -> {certificate name}
Once located, select your certificate and then can use the Actions (POST, DELETE) tab in the right hand pane to delete the certificate. You should then be able to redeploy.