tickets #90521
closedbeans.opensuse.org - permissions issue between apache and dehydrated [was: beans.o.o down]
100%
Updated by cboltz about 3 years ago
- Subject changed from beans.opensuse.org down to beans.opensuse.org - permissions issue between apache and dehydrated [was: beans.o.o down]
- Assignee set to lrupp
- Priority changed from High to Normal
Fixed for now - the issue was
[ssl:emerg] [pid 23864] AH02565: Certificate and private key beans.opensuse.org:443:0 from /etc/apache2/ssl.crt/cert.pem and /etc/apache2/ssl.key/privkey.pem do not match
and that was caused by a permission issue on /etc/apache2/ssl.key/ - dehydrated didn't have permissions to access this directory, and therefore couldn't update privkey.pem there.
IIRC I already "fixed" this in the past (by adding group permissions and an ACL), but the group permissions were probably reset by some apache update - and that also means the problem will come back with the next apache update.
-> I'll keep the ticket open until we found a more permanent solution (maybe a different location for the certificate that doesn't get its permissions reset?).
Lars, since you did most of the work on matomo - any proposals or preferences? ;-)
Updated by lrupp about 3 years ago
- Status changed from New to Feedback
- Assignee changed from lrupp to cboltz
Thanks for fixing it and identifying the root case as well!
cboltz wrote:
-> I'll keep the ticket open until we found a more permanent solution (maybe a different location for the certificate that doesn't get its permissions reset?).
Storing own SSL certificates out of the usual places seems to be the "best practice" (me remembers that we do this in other areas as well).
As we need to store certificates for different services and might need to patch them (apparmor) to get permission to a central directory, our current approach was always to use a directory below the configuration directory of the specific service.
Apache -> /etc/apache2/certs/
Nginx -> /etc/nginx/certs/
haproxy -> /etc/nginx/certs/
ldap -> /etc/openldap/certs/
...
Most of the time, the apparmor profiles (and other settings) allow the daemons to read in their config directory and any sub-directory. So no special handling of apparmor profiles or other settings is needed in this case.
What do you think?
Updated by cboltz about 3 years ago
/etc/$program/certs is one option.
The other option is to just leave the certs in /etc/dehydrated/ - if your profile includes abstractions/ssl_certs and abstractions/ssl_keys, it already allows reading certs in the usual locations (including /etc/dehydrated). (BTW: That's what I do on my own server.)
Another option would be to copy the certs as root (not as user dehydrated) to avoid the permission problem.
One more option would be to package /etc/apache2/ssl.key with root:root 750 so that (manually added) ACLs keep working.
Which easter egg do you like most? ;-)
Updated by cboltz over 2 years ago
Fixed once more - and noticed that someone (maybe Lars?) created a broken sudoers config two months ago:
cboltz@matomo:~> sudo su
/etc/sudoers.d/dehydrated:3:53: syntax error
/usr/bin/chmod u+rwX,g+rwX,o-rwX /etc/apache2/ssl.key/*, \
^~~~~
[sudo] password for cboltz:
Wild guess: sudo probably doesn't like the commas in the chmod command.
I have now created a cronjob that does a chmod g+x /etc/apache2/ssl.key once per day (via crontab -e). That's still a bit racy and will fail if we have an apache update and a certificate update the same day, but I prefer that risk over "always fails" ;-)
Updated by lrupp over 2 years ago
- Status changed from Feedback to Closed
- % Done changed from 0 to 100
Fixed by using the postrun-hook now inside the dehydrated.service file.
The positive effect: our apache now supports (per default) the ECDSA certificate, while allows clients to fall back to RSA - both signed by Let's encrypt.