Apache2 cant access letsencrypt certificate


#1

I just set up a VPS running ubuntu 16.04 with apache2. VPS has root login disabled, and I’ve given my own user account sudo permissions

I installed apache2 with sudo apt-get install apache2 . Certbot installed with sudo apt-get install python-letsencrypt-apache

I’m able to generate the certificate files OK, but apache cant seem to access the files:
Running apachectl configtest gives me:

AH00526: Syntax error on line 33 of /etc/apache2/sites-enabled/domain.net-le-ssl.conf:
SSLCertificateFile: file '/etc/letsencrypt/live/domain.net/fullchain.pem' does not exist or is empty
Action 'configtest' failed.

I think this is a permissions issue because I cant cd into /etc/letsencrypt/live either

Apache also doesn’t start after reboot. Is this because I dont have a root user account?

Whats the correct way to setup apache2 and letsencrypt (with, or without, root access)?


#2

certbot sets file permissions so that only root can read the private key. By default (at least on Debian/Ubuntu), apache spawns its first (master) process as root, parses the configuration and reads things like certificates and private keys. Then it spawns worker processes as non-root (typically www-data).

Note that your system still has a root user, your system likely is just set up so that you can’t login as root as such (though you can use it via sudo).

Have you made any modifications to that default behavior? In that case, you’d have to change the file permissions in /etc/letsencrypt/live/example.com to allow whatever user is launching apache to read those files (and possibly repeat that process after each renewal).


#3

instead of changing the permissions of that directory, would it be safe to just add my user to the www-data group? Does that achieve the same thing assuming my account has sudo privs?


#4

If by “your user” you’re referring to the user you use to login (via SSH), that wouldn’t change anything. The relevant user would be the one starting the apache master process. By default, that’s root on Debian/Ubuntu, and the fact that you cannot login via root doesn’t affect that - it’s still root, unless you modified your apache (or I suppose systemd) configuration. If that’s been changed to a different user, I don’t think there’s a way to do this that doesn’t involve changing the file/directory ownership.

I assume you can read files in /etc/letsencrypt/live via sudo, or does that not work either?


#5

yes I can use sudo to read files in the live directory

How do I check which user is starting the apache process?


#6

ps aux | grep apache should show a bunch of apache processes running under www-data, as well as one under root (or a different user if it’s been changed). Should be the one with the lowest PID.


#7

Hold on. Are we sure this is a permission issue? The error message itself was:

Does that path exist? It’s a symlink; does its target exist? Is it empty? Is there a typo in the Apache configuration? Is there a syntax error?

It’s normal for your personal user to lack permission to visit /etc/letsencrypt/live. That doesn’t mean Apache can’t.


#8

yes if I sudo I can see the contents of that directory and everything is where they should be

I just checked users running apache processes and I can see root and www-data. So this would suggest my setup is default and nothing has changed?

Whats the next step here given that apache is started by root, but its still not able to find the certificates?


#9

looks like you have to edit the file (domain.net-le-ssl. conf) in /etc/apache2/sites-available/.

Because the value given for

SSLCertificateFile is not correct / not existing.

the value is a fullchain-certificate but the question is if you have created a fullchain-certificate?
Seems like you havent (i think you have replaced your Domain with domain.net in the error log. am i right?)

and you said via sudo you can actually access the files so you can fix it. i would first try to comment the line out. restart apache service. try your configtest.


#10

Yep, that would indicate this is a default configuration.

Are you running apachectl configtest without sudo by any chance? In that case, you’d spawn apachectl without the ability to read root-owned files. Similarly, if you use service apache start or something like that, you’d want to do that as root via sudo.


#11

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