Files aren't created


#1

Hello,

The issue is that the key files aren’t created inside the webroot folder.

OS: CentOS 6.7
cPanel/WHM
Command Line: # ./letsencrypt-auto certonly --webroot -w /home/USERNAME/public_html -d DOMAINNAME.COM

Output:

Failed authorization procedure. DOMAIN.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://DOMAIN.com/.well-known/acme-challenge/pnZ6e6CK4x7IL5r_bIUGfnd36Zp4Yo4W1IlpqdN_Vpo [xx.xx.xx.xx]: 404

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: DOMAIN.com
   Type:   unauthorized
   Detail: Invalid response from http://DOMAIN.com/.well-known/acme-
   challenge/pnZ6e6CK4x7IL5r_bIUGfnd36Zp4Yo4W1IlpqdN_Vpo
   [xx.xx.xx.xx]: 404

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A record(s) for that domain
   contain(s) the right IP address.

Debug Log (Verbose -vvvv): http://pastebin.com/vBGv9tac

Any suggestions?

Note: Replaced domain name with DOMAIN, username with USERNAME, IP with xx.xx.xx.xx.

Best Regards,


#2

Are you happy to provide your domain name ?

If you create a file (such as “test”) in /home/USERNAME/public_html/.well-known/acme-challenge/test with plain text content ( “worked” ) … can you then reach it from elsewhere on the internet at DOMAIN/.well-known/acme-challenge/test ?


#3

Thanks for your reply.

Domain name is related to a customer so it won’t be nice to provide it.

Regarding the test I did it already and can reach it from anywhere, also checked DNS and .htaccess file and no issues at all.


#4

The log claims the files were successfully created, and then cleaned up at the end of the run.

Is it possible that’s so? Or are you confident that the files never exist at all, even while the Let’s Encrypt client is running?


#5

I put inotify on the directory and files never exists.


#6

Is this a regular local filesystem, or something like a NFS mount or some other kind of remote/distributed FS?


#7

No, Regular filesystem working on EXT4


#8

Are you certain inotify is working as expected? (Happy to test with a working client setup if you want to share how you’re doing it.)

I did some debugging of the webroot plugin source. This is the part that’s saving the challenge files:

def _perform_single(self, achall):
        response, validation = achall.response_and_validation()

        root_path = self.full_roots[achall.domain]
        validation_path = self._get_validation_path(root_path, achall)
        logger.debug("Attempting to save validation to %s", validation_path)

        # Change permissions to be world-readable, owner-writable (GH #1795)
        old_umask = os.umask(0o022)

        try:
            with open(validation_path, "w") as validation_file:
                validation_file.write(validation.encode())
        finally:
            os.umask(old_umask)

        self.performed[root_path].add(achall)

        return response

That log line (Attempting to save validation to ...) is included in your log as well. There’s no code path that wouldn’t lead to the file being written, and if there’s an error while storing the file, you’d see an exception (like OSError: [Errno 2] No such file or directory: ..., or whatever the error is).


#9

Yes, and to be completely sure, I watched the directory manually while trying to generate certificate.

Regarding the code, I’ve double checked the log and yes there’s an attemption to write files but nothing is written.

Do you think server security has to do anything with this? I’m using SuPHP, ModSecurity and SuHosin.


#10

So the files are being created, but they’re empty?

Have you checked your system logs for anything interesting? I suppose something like SELinux/AppArmor could be interfering, though I’m not sure why this wouldn’t at least trigger an exception.


#11

I’ve checked again now and found out that files are written with a content then removed again in a second, as @tialaramex stated above.

Message is 404 not found, which is happening because the files are created with root UID and GID, but the website is working as a user, so I guess this is the issue, but how to fix it?


#12

Hmm, the files are created as word-readable, plus IIRC apache would yield a 403 instead of a 404 if it’s about the file permissions.

Is there anything in your apache error log? That one might have more details.


#13

Apache throws this error:

Caught race condition abuser. attacker: 560, victim: 0 open file owner: 0, open file: /home/USERNAME/public_html/.well-known/acme-challenge/SihjQnu4sOO-bTXEaasRAsQUsWngUMtsvZJyc-BPSXY

Because the files are created with root and the handler is SuPHP so files created have to be made with user permissions not root permissions, any ideas?


#14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.