mattermost will letsencrypt nicht lesen

peterle

peterle

Forenkasper
Ich spiele ein wenig mit mattermost rum und würde es natürlich gerne dazu bringen eine verschlüsselte Verbindung aufzbauen.

Nun mag er wohl aktuell kein letsencrypt und der Server saugt sich eh seine Zertifikate automatisch runter und füttert die dem Apache zu. Das funkttioniert so weit.

Wenn ich allerdings mattermost als Pfad für Zertifikat und Schlüssel den Pfad zu letsencrypt in /usr/local/ext/letsencrypt angebe, dann meldet er permission denied. Wenn ich aber die beiden Dateien in sein Verzeichnis kopiere, dann liest er sie problemlos ein.

Wie kriege ich denn einen user mattermost:mattermost dazu unter /usr/local/etc/letsencrypt/.../LINKZUDATEI diesem Link zu folgen und die Datei zu lesen?
Von den Rechten her, müßte das eigentlich alles kein Thema sein.
 
Hi,

lass mal bitte die Berechtigungen anzeigen:
Code: 
# namei -l /usr/local/etc/letsencrypt/.../LINKZUDATEI

Rob
 
Um das Problem zu umschiffen, habe ich eine Gruppe ssl-cert, die Zugriff auf die Zertifikate hat. Dann könntest du dem Benutzer mattermost die Gruppe überbraten.

Falls du certbot verwendest, musst du nach jedem Update die Rechte wieder neu setzen.
 
Ok, also ...
Code: 
# ls -la /usr/local/etc/ | grep letsencrypt
drwxr-xr-x  8 root  wheel  8 Mar  5 11:11 letsencrypt

# ls -la /usr/local/etc/letsencrypt | grep archive
drwx------  3 root  wheel  3 Nov 28 21:04 archive

# ls -la /usr/local/etc/letsencrypt/archive/DOMAIN/
total 26
drwxr-xr-x  2 root  wheel  10 Jan 27 22:22 .
drwx------  3 root  wheel  3 Nov 28 21:04 ..
-rw-r--r--  1 root  wheel  1854 Nov 28 21:04 cert1.pem
-rw-r--r--  1 root  wheel  1854 Jan 27 22:22 cert2.pem
-rw-r--r--  1 root  wheel  1647 Nov 28 21:04 chain1.pem
-rw-r--r--  1 root  wheel  1647 Jan 27 22:22 chain2.pem
-rw-r--r--  1 root  wheel  3501 Nov 28 21:04 fullchain1.pem
-rw-r--r--  1 root  wheel  3501 Jan 27 22:22 fullchain2.pem
-rw-r--r--  1 root  wheel  1704 Nov 28 21:04 privkey1.pem
-rw-r--r--  1 root  wheel  1704 Jan 27 22:22 privkey2.pem

Mein Problem ist jetzt vermutlich der hier:
Code: 
# ls -la /usr/local/etc/letsencrypt | grep archive
drwx------  3 root  wheel  3 Nov 28 21:04 archive

An den Rechten und Besitzern von letsencrypt will ich nicht packen, denn sonst müsen wir ja bei jedem Update da dran ...

Ich frage mich jetzt allerdings, warum mein Apache die lesen kann, aber mattermost nicht?
Allerdings habe ich mir die Frage auch noch nie gestellt.

Wenn ich nun eine Gruppe ssl-cert baue, wie Zuglufttier das vorschlägt ... wie kriege ich die denn dann dazu, dort lesen zu dürfen, was alle anderen eigentlich nicht dürfen ... ich denk und denk ... ich brauch jetzt erst mal ein Getränk ... oder einen brauchbaren Hinweis in die richtige Richtung ...
 
peterle schrieb:
Ich frage mich jetzt allerdings, warum mein Apache die lesen kann, aber mattermost nicht?
Allerdings habe ich mir die Frage auch noch nie gestellt.
Zum Vergrößern anklicken....

Weil Apache im Kontext root startet und die Rechte erst herabsetzt, nachdem die Zertifikate geladen wurden. Anders kann ein Dienst auch nicht an die Ports <1024 binden.

Rob
 
zuglufttier schrieb:
Um das Problem zu umschiffen, habe ich eine Gruppe ssl-cert, die Zugriff auf die Zertifikate hat. Dann könntest du dem Benutzer mattermost die Gruppe überbraten.

Falls du certbot verwendest, musst du nach jedem Update die Rechte wieder neu setzen.
Zum Vergrößern anklicken....

Mal von der Grundidee her - wenn wir letsencrypt in Ruhe lassen und einfach eine Kopie davon machen, die wir der Gruppe ssl-cert zuweisen und die Rechte lockerer setzen ... dann bei jeder Ausfürhung von certbot prüfen, ob es eine Differenz in den Dateien gibt und falls ja -> werden die Dateien neu kopiert und die Rechte/Besitzer dort neu gesetzt, um anschließend alle abhängigen Dämonen neu zu starten/laden.

Finde ich ein wenig von hinten durchs Knie, aber eine andere schlaue Lösung fällt mir leider auch nicht ein.
 
Certbot hat doch m.W.n. Hooks? Da könntest du doch einfach ein Script erstellen, das dir die Certs irgendwo hin kopiert wo mattermost zugriff drauf hat und den Owner der Kopie ändern.
 
Also ich mache da keine große Kunst aus dem Thema und lasse das hier so in meiner crontab laufen:

Code: 
certbot renew --quiet
chgrp -R ssl-cert /usr/local/etc/letsencrypt
chmod -R g=rX /usr/local/etc/letsencrypt

Danach lade ich noch ein paar Dienste neu, die das nicht selber erkennen können, dass sich was geändert hat.
 
zuglufttier schrieb:
Also ich mache da keine große Kunst aus dem Thema und lasse das hier so in meiner crontab laufen:

Code: 
certbot renew --quiet
chgrp -R ssl-cert /usr/local/etc/letsencrypt
chmod -R g=rX /usr/local/etc/letsencrypt

Danach lade ich noch ein paar Dienste neu, die das nicht selber erkennen können, dass sich was geändert hat.
Zum Vergrößern anklicken....

Ich mag ja schlichte Lösungen, auch wenn es etwas holzhammerartiges hat.

foxit schrieb:
Bestes Tool dafür: "getssl" [1]. Das ist ein einfaches Bash-Skript.

[1] https://github.com/srvrco/getssl
Zum Vergrößern anklicken....

Der klingt auch gut, damit spiele ich mal rum.
 
Ne, noch nicht! Ich habe bei mir den certbot eingerichtet und es läuft, deswegen schraube ich da nicht weiter. Aber ich habe von acme.sh bisher gutes gehört und würde es bei einer Neuinstallation mal probieren.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben