HTTP-01 challenge file does not get created

[martinl88]

Describe the bug HTTP-01 challenge fails with this: Exception while executing function: IssueCertificate Orchestrator function 'IssueCertificate' failed: The activity function 'CheckHttpChallenge' failed: "http://domain-name-here.com/.well-known/acme-challenge/sTjMiwmRnjPJqz4R-puKojeH_LDtXtyEWQLUcVyFMBI is NotFound status code.". See the function execution logs for additional details.

Environment (please complete the following information):

• App Service OS: Windows
• App Service Type: Code
• Runtime Stack: .NET Core
• Certificate Type: Zone apex, Sub-domain

Additional context I have Acmebot working on several sites just fine.. except on one. For some unknown reason, challenge files are not created in ".well-known/acme-challenge" folder (so failing with the NotFound status code is the logical outcome). The question is, why aren't the files there in the first place.

If I place a temporary file in the ".well-known/acme-challenge" folder, I can access it with the browser just fine.

I've tried to crawl through the logs but have failed to find any clue exactly what is failing and why. Can you point me in the right direction? Thanks.

[shibayan]

It's a strange problem. I'm trying to solve this problem.

• Did something that was originally working suddenly stop working? Or has it never worked?
• Has web.config been created in the acme-challenge folder?
• Open the Application Insights created with Acmebot and check the "Dependencies" under "Failures" as shown in the image below. If there are any errors, they should be logged.

[martinl88]

Hi! Thank you so much for pointing me in the right direction. All that time I was analyzing the Operations log, I never thought to look at the Dependencies. From there I found out the PUT requests were getting 403 errors. After some brainstorming, we discovered that someone had put IP restrictions on the management API. That removed, certificate request went through as it should!

[shibayan]

Thanks for sharing the error cause. It is a problem that there is no error in advance when the management API cannot be accessed, so I will improve this as a separate issue.