Challenge fails with Connection refused (challenge type http-01)

[YetaWF]

I have been tracking down this problem. I have a seriously underpowered ATOM server where lots of problems like thread starvation, low memory situations, low cpu resource, etc. are found. This is part of edge testing. I found that one of my Docker containers was unable to obtain a new cert even though this worked fine on a "normal" system (i.e., with enough resources).

The call to services.AddFluffySpoonLetsEncrypt will start the renewal process by calling RenewCertificateIfNeeded.

The call to app.UseFluffySpoonLetsEncrypt() will setup the letsencrypt challenge response handling.

Unfortunately, in my case due to the weak server, the LetsEncrypt challenge to my server arrives BEFORE the call to UseFluffySpoonLetsEncrypt is even made, so my server can't respond to the challenge, hence the "Connection refused" response.

The fact that the pipeline isn't ready (and can't be ready) when AddFluffySpoonLetsEncrypt is called and issues the renewal is a problem, at least in my scenario. It works fine on a reasonably well powered server, but with few available threads any server could (in theory) run into this problem.

I think AddFluffySpoonLetsEncrypt shouldn't issue the renewal, Instead, the renewal should be made in UseFluffySpoonLetsEncrypt. At this point enough of the pipeline is available to respond to the challenge. I'll experiment with this and may submit a PR if I find a decent solution.

BTW, this problem caused me to find https://github.com/ffMathy/FluffySpoon.AspNet.LetsEncrypt/pull/35 when I tried retryandlog as a workaround :-)

[YetaWF]

logandretry works as a workaround (after https://github.com/ffMathy/FluffySpoon.AspNet.LetsEncrypt/pull/35). But the underlying problem still exist and retry is probably not a good option for production certs. We could accidentally exhaust the daily allowed requests for a domain.

The server won't start listening on the defined ports until the Configure method in the Startup class ends. This means that any code that does some form of lengthy initialization in the Configure method, will trigger this problem, because the LetsEncrypt challenge arrives before Configure ends.

[willdean]

Latest versions (post #75) have a RenewalServiceStartupDelay option, which allows you to inhibit the renewal service even further, though I think there had been other changes which delayed it until further into startup.

[ffMathy]

I think I may have time for this after the 15th. Sorry for that - super busy these days.

[YetaWF]

As far as I know this was addressed in https://github.com/ffMathy/FluffySpoon.AspNet.EncryptWeMust/pull/37 At least on my server where I observed and the reported the problem, that PR did address the issue Or was this thread hijacked for an issue with renewals?