App Service Managed Certificates error #5006
-
|
I've run into a problem when deploying a bicep script with an web app, DNS crecord (in Azure), host name binding and eventually a app service managed certificat. Deployment always fails when creating the certificat.
I have a similar script for setting up an Function App - only diffrerence is that this script creates the app service plan also, while this one uses an existing ASP. Facts:
The module for creating the managed certificate is the following: Any help og hints to solving this is greatly appreciated! |
Beta Was this translation helpful? Give feedback.
Replies: 10 comments 63 replies
-
|
There is a chain of dependencies needed for this to work. Essentially you can get the free cert if you have mapped the DNS name alias to the WebSite used in the AppService. https://docs.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-custom-domain?tabs=cname Before you can map the domain, you need to prove that you own it. If you have these steps covered, let me know and we can move onto the next part. |
Beta Was this translation helpful? Give feedback.
-
|
So I looked through the reference template and only difference is the verion, which I bumped from 2020-06-01 to 2021-02-01 and the password parameter. Changing the version also stopped the bicep linter from requiring the password paramter. However, I'm hitting the same issue. Facts.
|
Beta Was this translation helpful? Give feedback.
-
|
do you have a version of your code in a public repo to share? otherwise perhaps share it here? Do you have the binding depending on the certificates? e.g. i reference resource certificates 'Microsoft.Web/certificates@2021-02-01' = if (contains(ws,'customDNS') && bool(ws.customDNS)) {
name: toLower('${WS.name}.${Global.DomainNameExt}')
location: resourceGroup().location
properties: {
canonicalName: toLower('${WS.name}.${Global.DomainNameExt}')
serverFarmId: resourceId('Microsoft.Web/serverfarms', '${Deployment}-asp${ws.AppSVCPlan}')
// domainValidationMethod: 'http-token'
}
}
resource extDNSBinding 'Microsoft.Web/sites/hostNameBindings@2021-02-01' = if (contains(ws,'customDNS') && bool(ws.customDNS)) {
name: toLower('${WS.name}.${Global.DomainNameExt}')
parent: WS
properties: {
siteName: WS.name
hostNameType: 'Verified'
sslState: 'SniEnabled'
customHostNameDnsRecordType: 'CName'
thumbprint: certificates.properties.thumbprint
}
} |
Beta Was this translation helpful? Give feedback.
-
|
@jnus Did you manage to get this working without the delay or error? |
Beta Was this translation helpful? Give feedback.
-
|
No still haven't found the issue. The script never reaches the binding, due to it failing in the certificate step. ... appreciate the help! |
Beta Was this translation helpful? Give feedback.
-
|
okay sounds good. I assume this is set correctly already if it works in the portal, however your domain Nameserver records are updated to the Azure DNS servers? whois companywebsites.net Admin Email: [email protected] |
Beta Was this translation helpful? Give feedback.
-
|
@brwilkinson - ok - got a stripped copy of the code publish on my GH account -> https://github.com/jnus/bicep-managed-cert-error The domain being used, in this case segeswebsites.net, is managed by Azure DNS and as you also pointed out, it actually works if I do the last couple of steps in the portal. It looks like a delay issue, since the cert is created and ready to use. |
Beta Was this translation helpful? Give feedback.
-
|
okay, thanks for sharing. This is what you have: resource webAppCustomHost 'Microsoft.Web/sites/hostNameBindings@2020-06-01' = {
name: '${webAppName}/${webAppName}.${dnsZone}'
dependsOn: [
cnameRecord
]
properties: {
hostNameType: 'Verified'
sslState: 'Disabled'
customHostNameDnsRecordType: 'CName'
siteName: webApp.name
}
}
// App Service Managed Certificate -> https://wp.sjkp.dk/taking-azure-bicep-for-a-spin/
module certificate '../certificates/app-service-managed-certificate.bicep' = {
name: '${webAppName}.${dnsZone}'
dependsOn: [
webAppCustomHost
]
params: {
serverFarmId: serverFarmId
domainName: '${webAppName}.${dnsZone}'
location: location
}
}This is what I found works: resource certificates 'Microsoft.Web/certificates@2021-02-01' = if (contains(ws,'customDNS') && bool(ws.customDNS)) {
name: toLower('${WS.name}.${Global.DomainNameExt}')
location: resourceGroup().location
properties: {
canonicalName: toLower('${WS.name}.${Global.DomainNameExt}')
serverFarmId: resourceId('Microsoft.Web/serverfarms', '${Deployment}-asp${ws.AppSVCPlan}')
// domainValidationMethod: 'http-token'
}
}
resource extDNSBinding 'Microsoft.Web/sites/hostNameBindings@2021-02-01' = if (contains(ws,'customDNS') && bool(ws.customDNS)) {
name: toLower('${WS.name}.${Global.DomainNameExt}')
parent: WS
properties: {
siteName: WS.name
hostNameType: 'Verified'
sslState: 'SniEnabled'
customHostNameDnsRecordType: 'CName'
thumbprint: certificates.properties.thumbprint
}
}What are the differences?
|
Beta Was this translation helpful? Give feedback.
-
|
Hi @brwilkinson - been going forth and back regarding this issue, looking for an error 40 from my end. Still haven't identified the problem. Create certificate prior to the host binding
Minimal example producing the error: https://github.com/jnus/bicepManagedCertificate/blob/master/certificate-creation-requires-hostname.bicep I've got a working example for a function app using the approach specifiered here -> https://wp.sjkp.dk/taking-azure-bicep-for-a-spin/ Basically the following approach:
|
Beta Was this translation helpful? Give feedback.
-
If you have create the DNS record first then I believe that should stop this error. |
Beta Was this translation helpful? Give feedback.
-
|
Here is the working sample: https://github.com/brwilkinson/AzureDeploymentFramework/blob/main/ADF/bicep/x.appService.bicep Looking at your sample, you are creating the
Then after that since you have the DNS created you avoid the error above, when you create the Certificate. Looking below, you have step 2. running at the same time.
Also in the sample that you say is working, doesn't include setting the DNS records
|
Beta Was this translation helpful? Give feedback.
-
|
First of all, appreciated you hanging in there. There's definitely some life cycle regarding bicep/ARM that I haven't quite figured out yet. Changing the order to your example:
With this approach, I get the error Changing it to the numbering in your post above gives the samme error.
My example is located here -> https://github.com/jnus/bicep-managed-cert-error Question: |
Beta Was this translation helpful? Give feedback.
-
|
Error on my part, with wrong domainName. Still using a custom domain and at this stage, the repo produces 'Cannot find Certificate with name easycow-si-api-wa.segeswebsites.net'. Yeah - I noticed this also. |
Beta Was this translation helpful? Give feedback.
-
|
okay, let me know if it's still not working after you make any updates on that shared repo and I can take another look. |
Beta Was this translation helpful? Give feedback.
-
|
I'm pretty sure I've structured my script as your example. Even tried to set a dependency from the SNI enabled binding to the certificate creation step. Still getting the 'Cannot find Certificate with name easycow-si-api-wa.segeswebsites.net' error. |
Beta Was this translation helpful? Give feedback.
-
|
I pulled down your changes and created a new site and it works as expected the first time. Everything looks good. If you look in the portal, are you sure there are no errors on your deployment? Perhaps share what your current error is? |
Beta Was this translation helpful? Give feedback.
-
|
Hm - that's interesting. The error I'm getting from az is: Looking in the activity log for the resource groups, I see 5 error:
Anyway to see more verbose logging for deployment? |
Beta Was this translation helpful? Give feedback.
-
|
Hm - that's interesting. The error I'm getting from az is: Looking in the activity log for the resource groups, I see 5 error:
Anyway to see more verbose logging for deployment? |
Beta Was this translation helpful? Give feedback.
-
|
or something else on the app service plan.. since I don't think the error is related to what is in these templates, if it works for me? Although it is confusing if the cert shows as being created. Perhaps check this list and see if anything stands out OR stand up a new app service plan to test? |
Beta Was this translation helpful? Give feedback.
-
|
any of these ?
|
Beta Was this translation helpful? Give feedback.
-
|
Quick update: Created a dedicated ASP and this actually works (finally)!! But finally some traction regarding this issue! Really appreciate you hanging in there! |
Beta Was this translation helpful? Give feedback.
-
|
okay that is good to hear, glad you were able to get things working. Perhaps redeploying the ASP would ensure it's running under the latest API settings?! Following up with the support tickets sounds like a good plan. |
Beta Was this translation helpful? Give feedback.
-
This most likely succeeded because your dedicated ASP was in the same resource group as your app. I have found that Microsoft.Web RP fails to create a certificate on the first deployment attempt when deploying the certificate to a different resource group than the referenced ASP. The second deployment attempt succeeds. You will notice that regardless of the resource group you deploy your Microsoft.Web/certificates to, it will actually be deployed to the resource group hosting the ASP referenced by serverFarmId (or more accurately to the resource group linked to the webspace of the ASP). I found a related issue reported in Azure PowerShell Azure/azure-powershell#15848, but the root cause is in the Microsoft.Web RP. |
Beta Was this translation helpful? Give feedback.
-
|
To summarize this thread/discussion. You can deploy a free Certificate for your web app as documented here: The steps are:
Example here: Since step 3 and 5 share the same resource type, using a module to call it twice. Input for the above template is below. "FunctionInfo": [
{
"Name": "DIS02",
"kind": "functionapp",
"AppSVCPlan": "ASP01",
"saname": "data",
"runtime": "dotnet",
"subnet": "snMT01",
"preWarmedCount": 1,
"customDNS": 1,
"initialDeploy": 1 // <-- leave this as 1 to start then set it to 0 anytime later.
}
]The issue behind this thread was related to having an old App Service Plan/ServerFarm, so you likely want to deploy your ServerFarm to ensure it has been deployed with some recent API to ensure this works successfully.
@jnus let us know if you have any additional information after your investigation into your App Service Plan. |
Beta Was this translation helpful? Give feedback.
-
|
So we dug a bit further and the issue is that the particular ASP does not support the newer API versions and there's no upgrade path. One need either to create a new ASP and redeploy, or create the ASP in the same RG and region and clone the app. One way to test whether your ASP is running with an update to date API version, is whether you can upgrade to a v3 SKU. E.g. if greyed out, you're running on an old API which is not upgradable.
The new v3 SKU's seems to be released 2020 Q3 and introduced some breaking changes to existing ASP's, which means they cannot be upgraded. Guess I missed that announcement ;) Ref: https://docs.microsoft.com/en-us/azure/app-service/app-service-configure-premium-tier#unsupported |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the follow up @jnus |
Beta Was this translation helpful? Give feedback.
-
|
@brwilkinson What's the benefit of your approach (using In my app, this seems to work perfectly (can be run once or multiple times without errors, and doesn't disable SSL during subsequent deployments), so I'm wondering if there's something I'm missing? |
Beta Was this translation helpful? Give feedback.
-
|
This thread is 2 years old, so that file has changed quite a bit since this was originally written. I use the test Resource Exists mainly to merge app config. Since I am using it there, I used it here at well. It just saves the need to do any put operation on subsequent deploys. I can't say for sure what you mentioned isn't a good idea, without doing testing, however it sounds reasonable. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the info and quick response. I'll give my modification a go, and see if I run into any issues. |
Beta Was this translation helpful? Give feedback.
-
|
Hello, I have a follow up to this discussion. The issue I'm facing is that I want to run the same code for subscription with custom domain and without, and I can't make conditional checks to work correctly. Same bicep code does not work for resources with custom and without custom binding, despite I added conditional statements all over the place for involved. I ended up creating this construction: Which is slightly rewritten version of @brwilkinson examples The problem is that certificate module will still be invoked, go over resources it has to create - conditional Any thoughts how can I resolve this situation and create code which will be working correctly for both cases - webapp with custom domain and webapp without one ? |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for dropping the convo mid-flight. I can't share code publicly anywhere. But, after some digging I identified the issue and fixed it. It was actually the same module naming but now because I used UtcTimestamp as a suffix - module name would be unique between deployments but ocasionally 2 iterations of cert loop would get the same timestamp, thus would cause same module name colission. It's less obvious in a console as one usually don't read timestamp part assuming it's unique. Replacing it with a fixed but iteration dependent token guaranteed that all module calls in a loop would get it's own unique deployment name in azure - fixed this problem in a better way. Problem was the same as before, it's module name, it just utcTimestamp has not enough uniqueness in a loop to correctly fix it. |
Beta Was this translation helpful? Give feedback.
-
|
sounds good, yes I would recommend having 'deterministic' deployment names and avoid dates. There is rarely a need to see old deployments and there is a deployment limit of 800, so re-using names makes sense. I personally use a nested approach so that I can easily follow the deployments in the portal to troubleshoot. The module name = the deployment name.... also when you reference other modules outputs you need the name to be known. // top level // second level //third level |
Beta Was this translation helpful? Give feedback.
-
|
Also thank you for the update, very happy to hear that you found the root cause ✅ |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
The limit is a subscription limit. .. the docs are here. It actually applies at most scopes MG/Sub/RG... The auto cleanup is enabled, and I am just guessing for the past 12 months or so. I haven't seen anyone hitting limits since it was turned on and it used to be quite common, so it appears to be doing its job. It's worthwhile noting that a deployment name also can only be used in a single region.... you can't use the same name across regions, unless you delete it first. i mostly tag all of my resources and deployments with a 'Deployment' https://github.com/brwilkinson/AzureDeploymentFramework/blob/main/ADF/bicep/01-ALL-RG.bicep#L74 var Deployment = '${Prefix}-${Global.OrgName}-${Global.Appname}-${Environment}${DeploymentID}'
module dp_Deployment_SA 'SA.bicep' = if (bool(Stage.SA)) {
name: 'dp${Deployment}-SA'The Prefix is a reference to the region.
SA nested under storage
SA-data nested under that...
SA-data-FileShare Etc. mainly doing this is really easy to troubleshoot and follow deployments to know what is going on. |
Beta Was this translation helpful? Give feedback.
-
|
Automating custom domains with TLS/SSL using ARM/Bicep/Terraform is honestly a pretty bad experience. It shouldn't be anywhere near this hard (should it?). The documentation and examples aren't doing much to help either. Are there any plans to improve the situation? |
Beta Was this translation helpful? Give feedback.
-
|
@janaka Custom domains with Azure App Service or in general? There's one part that is Resource Provider specific, and one part about domains/certs in general. Automating this with App Service is definitely harder than it should be. But there are some moving pieces underneath that contribute - if you've attempted hooking the App Service up to a private vnet you'll have noticed you need one inbound subnet and another for outbound traffic. Hence, this complication carries over to certificate enrollment which requires public line of sight reachable IP address for issuing a cert. If you look at a newer service (with a newer Resource Provider) like Container Apps it's also much easier to do both vnet integration and custom domains + certs. You can still trip it up by forgetting to do the DNS records correctly, but still less hard. Other than the Bicep team slapping the resource teams when they come up with non-IaC friendly services there's not much we can do I suppose... |
Beta Was this translation helpful? Give feedback.
-
|
Hi guys, I tried this but the certificate does not exist - because it is in keyVault?! I tried this but this does not deliver a thumbprint. What I am missing is a resource named ceritficate, similar to this but ../certificates@.. This just don't exists whyoever: What do I have to use instead to get easily an existing cert to use its thumbprint? Thank you for your help @brwilkinson `` |
Beta Was this translation helpful? Give feedback.
-
|
Ahh, I got it... Have to create the cert for web and then I can use it... |
Beta Was this translation helpful? Give feedback.
To summarize this thread/discussion.
You can deploy a free Certificate for your web app as documented here:
https://docs.microsoft.com/en-us/azure/app-service/configure-ssl-certificate#create-a-free-managed-certificate
The steps are:
Example here:
I updated this: https://github.com/brwilkinson/AzureDeploymentFramework/blob/main/ADF/bicep/x.appService.bicep#L66
Since step 3 and 5 share the same resource type, using a module to call it twice.
added this: https://github.com/brwilkins…