SSL Fails Setup

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. |, so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command: wp-config.php not writable

It produced this output:A definition of a site url or home url was detected in your wp-config.php, but the file is not writable. Set your wp-config.php to writable and reload this page.

SSL is not enabled yet.

Automatic certificate detection is not possible on your server

My web server is (include version):6.2

The operating system my web server runs on is (include version): Amazon Linux 2023

My hosting provider, if applicable, is: AWS

I can login to a root shell on my machine (yes or no, or I don't know): YES

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): NO

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): N/A

Hello @nexustech, welcome to the Let's Encrypt community. :slightly_smiling_face:

Here is a list of issued certificates the latest being 2023-04-15 (and the only certificate presently)

I do not know that command (what is it Word Perfect has some PHP configuration?).

Kindly wait to see if there are more knowledgeable Let's Encrypt community volunteers willing to assist.


You need to change the permissions on your wp-config.php file so that the settings for your WordPress Address and Site Address can be updated to HTTPS.


Oh, is WordPress also called wp?
I have always hear WordPerfect referred to as wp.
I get tired of overloaded terms, acronyms, and abbreviations. :frowning:


This is the command you likely want chmod - Wikipedia


I have changed the permissions on both wp-config.pho and .htaccess to 644 with no luck.

Try 777.


Also, the WP Address (URL and Site Address (URL) are greyed out in the GUI.

What user ID owns the command?
What user ID are you running the command as? Share the output it id

ls -l <path to>/wp-config.php 
1 Like

-rwxrwxrwx. 1 apache apache 3684 Apr 15 18:50 wp-config.php

1 Like

During installation steps it shows: "Your hosting environment does not allow automatic SSL installation. Please complete manually in your hosting dashboard."

The commands listed on my Linux instance to reference "apt-get" but they are not found on my AWS Linux 2023 instance.

I'm running it with as my admin account within the GUI. Is there a specific account that should be used?

I had only asked as part the the file permissions investigation portion.

1 Like

Never! Every time you chmod 777 an innocent kitten dies!

Seriously, there is (almost) never a good reason to use mode 777. Spend the time resolving the ownership issue and use an appropriate permission setting.

The wp-config.php file contains mysql credentials and must never have any permissions allowed for other. It is critical that the octal mode for that file ends in zero.


If it's a web access it won't matter. It's not like the php interpreter is going to magically enable writing to the file. I would challenge anyone to find a way through the web to exploit a 777 php script that's written correctly. Keep in mind that apache will have write access to that script via the user permission anyhow, so any other hole exposed through the web to write to that file would not need the 7 for other. I get what you're saying in principle though. :slightly_smiling_face: That permission was purely for test purposes. Technically 765 should be enough though to test.


I would be more concerned about local attacks from other users on a shared hosting system; the file with mode 777 would let other customers on the same server modify that script and, if they were so inclined, add malicious code to it.


They would still need to punch through the sandbox isolation to get to your data. I'd pay to watch that attempt. :grin: :popcorn:

There are numerous other safeguards behind credentials. If one even needs to remotely rely upon file permissions as the front line, that's a sad system indeed.

In short, sure it's good practice to carefully manage file permissions, but the actual risks of loose file permissions in a system like this are typically very low.


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