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. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
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
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.
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.
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. 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.
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.
