Project

General

Profile

tickets #90521

beans.opensuse.org - permissions issue between apache and dehydrated [was: beans.o.o down]

Added by hellcp 7 months ago. Updated 21 days ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Servers hosted in NBG
Target version:
-
Start date:
2021-03-31
Due date:
% Done:

100%

Estimated time:

History

#1 Updated by hellcp 7 months ago

  • Private changed from Yes to No

#2 Updated by cboltz 7 months 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? ;-)

#3 Updated by lrupp 7 months 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?

#4 Updated by cboltz 7 months 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? ;-)

#5 Updated by cboltz 3 months 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" ;-)

#6 Updated by lrupp 21 days 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.

Also available in: Atom PDF