Forum

It took me a long time to figure out the cause of this failure. Using Hiawatha 10.5 I ran:

letsencrypt request hostname

this resulted in the following error in error.log.

66.133.109.36|Thu 02 Feb 2017 19:53:20 -0500|/var/www/html/.well-known/acme-challenge/x6sfFvhi9evI8YrwCs5gEV1zkMcjECloFk1JIEiE5ZI|access denied via filesystem

I was able to suspend the letsencrypt command to prevent it from deleting the target file.
I was able to verify that the hiawatha program was running as a user that could access
the file.

While trying to debug it (btw how do I get more debugging info from hiawatha??) I finally figured
out that commenting out the directive:

NoExtensionAs = cgi

allows letsencrypt to retrieve the file.

I also use:

CGIextension = cgi

becuse one application (foswiki) has no extensions on the cgi's so I need this to make the
cgi's run.

I suspect that the cause of the error is that the target file that letsencrypt is retreiving
is treated as a cgi. Since it has no execute permission it can't be run. Hence there
was an error on the exec which resulted in "access denied via filesystem".

I can suggest a couple things here:

1) disable the NoExtenstionAs setting for the .well-known/acme-challenge directory
2) provide some more info about the access denied failure:
1) unable to read
2) unable to execute (exec failed etc.)

Also as an aside, adding a debug mode to the letsencrypt script that leaves the files
in place would be helpful.

-- rouilj

Change line 308 in src/session.c from '} else {' to:

    } else if (session->letsencrypt_auth_request == false) {

That appears to do the trick. Thanks for the fast feedback.