ASP.Net application interfering with remote host Let's Encrypt (via Plesk) installation?

Issue

So, to install Let's Encrypt SSL cert, I head over to my Plesk account, pick a domain or subdomain and click on Let's Encrypt then I only have a field to put in an email address, and a button to install.

To install, Let's Encrypt sends my site an HTTP request:

GET /.well-known/acme-challenge/n9cD8Lpv-woEU73NhCUdFyqOYMc5hrANF_byoiaYrZc - HTTP/1.1

If I create a fresh 'site' through Plesk, and install the cert, that GET request get's a nice 200 response and the SSL cert installs fine.

However, I had a 'sandbox' with no SSL installed, I then deployed an ASP.NetCore app to the 'sandbox' for staging and then tried to install the SSL certs. With an ASP.NetCore application running, when Let's Encrypt sends that GET request, it results in a 404 error and the installation fails.

Has anyone run into this? What do I need to configure? Is it MVC routes or maybe the AngularJS (~1.5) routes that is interfering?

I don't see a /.well-known/* directory anywhere, I'm not sure if it is hidden, but I can't get to it, so how would I know WHAT to configure, IF I needed to configure something in routes to allow the GET /.well-known/acme-challenge/*?

The remote host tech support is of no help. They told me to wait 72 hours because I tried to many times and I'm just locked out (which I'm not)

Here is the actual Plesk error message

Let's Encrypt SSL certificate installation failed: Challenge marked as invalid. Details: Invalid response from http://my-domain.net/.well-known/acme-challenge/AJsMc3HXiOZRGaFVsMR3uZEdYu1moJ2Po62t3e6uV10 [my-ip]: 404

I'm fairly sure I could 'work around' this by just deleting my site, installing the SSL certificate than uploading again, but I would like to know what is actually going on, and if I can handle it properly.

AFTERTHOUGHT

Let's Encrypt is a 30 day auto-renewing service. If my ASP.NET application is blocking the installation, then it will also block the automatic renewal, so I would have to remove my site every 30 days and re-deploy, unacceptable!

SOLVED Here is the solution to this very specific scenario.

There are other work around's that will work, and of course this solution only works on IIS web servers.

ASPNetCore MVC Routing Let Server Handle Specific Route

Solution

Doing a quick search yielded this little gem

Which seems to match your particular problem.

To get a certificate, let’s encrypt verify that you own the domain by requesting a file on your server. In this case, the file is not accessible (status 404). Let’s understand what happened.

IIS get the request, and find the associated web site. Then it executes handlers in order until one send the response. ASP.NET Core handler is the first to handle the request.

The challenge file is in the folder “.well-known/…”, but by default ASP.NET Core serves only files located in the folder “wwwroot” => so, a 404 response is send to the client. ASP.NET Core has handled the request; therefore, the IIS Static file handler is not called.

As a workaround, you can move up the “StaticFile” handler, but your website may not work as expected. A better solution is to instruct your ASP.NET Core website to send the file located in the directory “.well-known”.

This is possible by registering it:

public void Configure(IApplicationBuilder app, IHostingEnvironment env) {
    //...other configs

    app.UseStaticFiles(); // wwwroot
    app.UseStaticFiles(new StaticFileOptions
    {
        FileProvider = new PhysicalFileProvider(Path.Combine(Directory.GetCurrentDirectory(), @".well-known")),
        RequestPath = new PathString("/.well-known"),
        ServeUnknownFileTypes = true // serve extensionless file
    });

    //...other configs

    app.UseMvc();
}

This basically routes the call for the virtual path through core which grabs the physical path and provides the file content to the caller. This should now allow for the domain to be verified and let the certificate request process flow to completion as well as automatic renewals.

Check out the article and its suggested workaround as there don't seem to be too many additional steps involved.

Answered By - Nkosi