It produced this output:AH00526: Syntax error on line 30 of /etc/httpd/conf/httpd-le-ssl.conf: SSLCertificateFile: file '/etc/letsencrypt/live/onearth.studio/fullchain.pem' does not exist or is empty
My web server is (include version): Apache/2.4.48
The operating system my web server runs on is (include version): Linux 4.14.231-173.361.amzn2.x86_64
I can login to a root shell on my machine (yes or no, or I don't know): yes
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): /var not root-owned 48:48
The usual command to renew is sudo certbot renew, but:
This suggests along the way something terrible has happened on your Linux system: for some reason, the directory /var is owned by a non-root user, which is not standard and certbot seems to refuse to go further as long as /var isn't owned by root.
I'm not sure what happened to /var that now blocks certbot from access.
Let's have a look at: ls -l / | grep -E 'etc|var' cat /etc/letsencrypt/renewal/* find /etc/letsencrypt/ -name *.ini
[note: @OnEarth, when address individuals on this forum don't forget to include the preceding "@"]
Not finding an .ini file is not a problem.
I merely wanted to see the contents (if one existed).
Somehow/somewhere in your journey you have passed the entire /var directory to the sole control/access of the apache user/group.
This is probably going to create issues far outside of certbot - but I shall not digress form the problem at hand.
If you want to use certbot without addressing that ownership issue, you can simply make a new unique dedicated directory (outside of /var) to handle the challenge requests. Then update the .well-known/acme-challenge path to use the newly created folder in your web configs.
I can't say with any certainty.
I don't know what (if anything) now relies on that level of access.
I can only say with certainty that it doesn't make any sense; no single program should own that entire path.
Thx for you explanations, this might appended after I ran Certbot the first time (everything was working fine until now). I will give back root access to /var directory. Then what shall I do next (I do not want to make any mistake)?
Well, using --dry-run & -vv, I would continue to test certbot for errors.
[ I suspect that even /etc/letsencrypt/ might now also be owned by apache ]
In any case, I would continue fixing things until certbot passes the -dry-run tests.
[which might be simpler to do by changing the challenge path location - as explained previously]
[but who needs simple - we need certain!]
Unfortunately, I don't know what made the ownership change, so I can't be certain on how to undue it.