From time to time I run into this error when trying to get a Let's Encrypt certificate via the acme.sh script.
Sometimes it's the first time trying to get a Let's Encrypt certificate, and sometimes it worked previously but now suddenly doesn't work.
The error message is similar to:
domain.com:Verify error:Invalid response from https://example.com/.well-known/acme-challenge/1kSTnls6_vcku98gwLEUMQNnbl1cSY1pdBrPi7sJdos
Please add '--debug' or '--log' to check more details.
See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh
Adding the --debug option, reveals some log entries similar to:
Changing owner/group of .well-known to username:nobody
chown: changing ownership of /home/path/to/example.com: Operation not permitted
What's the solution?
Hopefully this will save others some time googling, or poring over the documentation, or reading through the closed GitHub issues.
First thing to check: does the website folder have an .htaccess file in it?
(By "website folder" we mean where the actual website files are stored, such as /home/youruser/public_html/path_to_your_domain.com
(Note that dot files like .htaccess are hidden by default in CPANEL file manager, so you might need to use an FTP app to check - or enable showing hidden files in the CPANEL file manager (there is a Settings button at top right))
If so:
a) Rename the .htaccess file (to .xxxhtaccess or etc)
b) re-run the acme.sh script
c) When successful, rename the .htaccess file back again
Some References:
acme.sh GitHub Issues
acme.sh Documentation
Related
I took over a website which I'm supposed to admin and somebody brought to my attention that certain Indexes and Files are available, which shouldn't be. I will be using dummy names.
You were able to access example.com/intern before, but I changed a line in /etc/apache2/apache2.conf according to this https://stackoverflow.com/a/31445273 . This worked partly, as I get a 403-Forbidden when I now navigate to example.com/intern and that's basically what I want.
However the directory intern governs a file called file.php.bak aswell as file.php. When I navigate to example.com/intern/file.php I get a white website. I am however not sure, if you are able to access file.php in another way, because the site does load and I don't get a 403 like before. What is way worse and the reason I am struggling with this is: If I go to example.com/intern/file.php.bak then my Browser (Firefox) offers me to download file.php.bak, which I can read in plaintext. I want all files in intern to not be accessible via the website, but I have no idea how to do this. Can anybody help?
Things I've tried:
Removing the Indexes from the apache2.conf file like mentioned above. It only puts the 403 on the directory itself and not recursively for all the files in it.
Writing a .htaccess file as described here: https://fedingo.com/how-to-prevent-direct-file-download-in-apache-server/ and putting it in intern with the same result as in 1)
Putting an empty index.html file in the intern directory. This leads to no more 403 in example.com/intern, but the download on example.com/intern/file.php.bak is still possible. I've also tried index.php with the same result.
File System:
The application runs from /var/www/application which is also the folder for the /var/www/application/index.php I want to use. The /var/www/application/intern directory is also there. While it isn't browsable anymore, the files in it still are accessible. /var/www/application/intern/file.php can be navigated to via example.com/intern/file.php, but it seems like it can't be downloaded or read as it results in a white page. /var/www/application/intern/file.php.bak can however be downloaded via example.com/intern/file.php.bak.
Let's say Apache document root is set to DocumentRoot "/folder_one/folder_two"
Placing files in a folder_one will prevent people browsing your apache server and requesting the files directly.
Place index file in folder_two and include some code such as PHP to tell apache to include whatever files you want from folder_one.
In this manor Apache will still be able to serve whatever files you want from folder_one and people will not be able to request the files directly as the are located in a directory above the Apache document root.
I'm working on a Symfony2 project at local server without any virtual hosting or something else. After I run the command php app/console assets:install --symlink, clear the cache and refresh the page none styles or javascript or images are loaded. Inspecting the source code and trying to access any of those assets I get this error:
You don't have permission to access
/cmplatform/web/bundles/clanmovilcommon/css/bootstrap.min.css on this
server.
What I need to change in my /etc/httpd/conf/httpd.conf to fix that problem? It's related to .htaccess problem or what?
This error is due to the user that you are currently logged in as not having correct to write to the /cmplatform/web directory. Or you have not got the root path set correctly in your apache.conf.
Can you confirm other pages / assets are being served correctly.
Take a look at who owns the directory and either adjust the write permissions or add your user / web server to own the directory or into the group.
This is quite a common issue - and care needs to be taken to ensure that write permissions for web, cache and log directories are set correctly to allow command line and web server (e.g. apache / nginx) users.
See http://symfony.com/doc/current/book/installation.html - permissions for some tips about fixing this.
I am learning how to use SQL, I set up a localhost, in the course of that journey, I was confronted to the issue of importing sql files into phpMyAdmin, I did the right click on config.inc.php and clicked on the Notepad++ that I previously installed, I typed in there the following code: $cfg['UploadDir']='c:\Files';, of course I created on the hard drive C the Files directory. Now that I came back into phpMyAdmin, clicked on my database, clicked on import, this is what I got as message:
The directory you set for upload work cannot be reached.
Can anyone help me here with this issue?
Your webserver probably doesn't have permission to read 'c:\Files' thus it is not a valid directory. Technically you would say this is out of the web root.
I suggest you set the upload directory to a subdirectory of your web server's root directory (or in the PHPMyAdmin web directory). Then if for your own ease of use you want it to be located at 'c:\Files' you can create a shortcut from the web root upload directory whatever you name it, and place the shortcut in 'c:' and name it 'Files'.
keep getting the following error when I try to upload an image for my user profile:
The specified file temporary://picture-1-1366485906.jpg could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log
I have a multsite installation meaning I have the following:
sites/domain1.com
sites/domain2.com
sites/domain3.com
It is not happening on the first domain, but on domains 2 and 3 it is happening.
Go to file system url of each website & make sure details are saved there properly.
Example:
http://domain2.com/admin/settings/file-system
I have to sync some folders from a linux server, to another.
We have created the RSA-Key and the authentication goes well.
When we launch an rsync command, some of the files gave birth to errors like:
rsync: readlink "/var/www/sestantemultimedia.it/xxecommerce/pub/.htaccess" failed: Permission denied (13)
Now, the directory /var/ (as well as other subdirectory) have the permits set to 755.
The files into the last directories have permits set like 644.
So, theoretically, permits as set right and I can read from the other server and copy my files.
What I am missing?
Ok, I just figured it out.
Someone (because we work together as a team) had done a change on the "final folder" so that "apache" user's group can't execute (so can't traverse) the folder itself.
In that way, although it is possibile for "other group" to execute, the sum of permits that we receive (we were into "apache" group) isn't enough for "execute" the folder and retrive the file.
We just change that scenario and now it works properly!