Hi,
Die Vorgeschichte:
wir benutzen seit längerem UCS mit installiertem Let’s Encrypt, unser Kopano nutzt ebenfalls die Zertifikate.
UCS ist 4.4-0 errata78, univention-letsencrypt ist in Version 1.2.2-8A~4.3.0.201901181305 installiert. Die Zertifikate wurden das letzte mal automatisch am 1. Mai 2019 erneuert. Da vor kurzem auch ein neuer Kernel verfügbar war wurde der Server am 3.5.19 neu gestartet. Seit diesem Neustart konnte der Benutzer ‘kopano’ nicht mehr auf die Zertifikate zugreifen. Die Ursache war recht schnell gefunden:
# getfacl etc/univention/letsencrypt/domain.key
# file: etc/univention/letsencrypt/domain.key
# owner: root
# group: root
user::rw-
user:www-data:r--
user:postfix:r--
group::---
mask::r--
other::---
Das Problem wurde auch sehr schnell gefixt, schlicht indem der Benutzer kopano zur ACL hinzugefügt wurde:
setfacl -m u:kopano:r /etc/univention/letsencrypt/domain.key
Nach dem Neustart der Dienste klappte dann alles wieder. So weit, so gut.
Warum ich hier schreibe, meine Frage: Ich konnte nicht herausfinden welcher Prozess oder welcher Dienst von letsencrypt die ACL der Datei domain.key setzte. Ich habe deshalb die Befürchtung das beim nächsten Lauf die ACL wieder auf “Standard” zurück gesetzt wird.
Vielleicht kann mir hier jemand helfen:
- welcher Prozess oder Skript setzt die ACL?
- Muss ich noch etwas tun um die von mir geänderte ACL dauerhaft zu setzen?
Vielen Dank und liebe Grüße Lutz
EDIT: Meine Frage ist sehr ähnlich zu Kopano ical - SSL not working und meine Frage wird in Mini-Howto: Kopano IMAP & Let's Encrypt beantwortet. --> self-solved 
Foren sind etwas tolles!