systemd-journal-gatewayd und Zertifikate
Hi, ich spiele im Moment ein wenig mit dem Journal und der Möglichkeit sich das via https anzeigen zu lassen. (http klappt schon ;) Ich habe via 'systemctl edit systemd-journal-gatewayd.service' eine Erweiterung der Unit angelegt in der steht: [Service] ExecStart= ExecStart=/usr/lib/systemd/systemd-journal-gatewayd --cert=/etc/ssl/server/log.crt --key=/etc/ssl/private/log.key cert und key sind im PEM-Format. Wenn ich das Gateway nun starte und mit systemctl status nach dessen Befinden schaue, sehe ich die Meldung "Failed to read key file: Permission denied" (und https klappt natürlich nicht). Die beiden Files haben die Rechte 400 und gehören systemd-journal-gateway. Wie mache ich es richtig? Bernd -- Die normative Kraft des Faktischen behindert die Entwicklung zum Besseren.
On 21.05.21 17:43, Bernd Nachtigall wrote:
Ich habe via 'systemctl edit systemd-journal-gatewayd.service' eine Erweiterung der Unit angelegt in der steht: [Service] ExecStart= ExecStart=/usr/lib/systemd/systemd-journal-gatewayd --cert=/etc/ssl/server/log.crt --key=/etc/ssl/private/log.key
cert und key sind im PEM-Format.
Wenn ich das Gateway nun starte und mit systemctl status nach dessen Befinden schaue, sehe ich die Meldung "Failed to read key file: Permission denied" (und https klappt natürlich nicht).
Die beiden Files haben die Rechte 400 und gehören systemd-journal-gateway.
Was sagt ls -ld /etc/ssl/private ? Viele Grüße Ulf
Hallo Ulf, Am 22.05.21 um 13:57 schrieb Ulf Volmer:
On 21.05.21 17:43, Bernd Nachtigall wrote:
Ich habe via 'systemctl edit systemd-journal-gatewayd.service' eine Erweiterung der Unit angelegt in der steht: [Service] ExecStart= ExecStart=/usr/lib/systemd/systemd-journal-gatewayd --cert=/etc/ssl/server/log.crt --key=/etc/ssl/private/log.key
cert und key sind im PEM-Format.
Wenn ich das Gateway nun starte und mit systemctl status nach dessen Befinden schaue, sehe ich die Meldung "Failed to read key file: Permission denied" (und https klappt natürlich nicht).
Die beiden Files haben die Rechte 400 und gehören systemd-journal-gateway.
Was sagt
ls -ld /etc/ssl/private ?
Na ja, der Ordner gehört natürlich root. Aber deine Antwort hat mich einen Schritt weiter gebracht. Obwohl in der Meldung von 'Key-File' die Rede war hat es geholfen auch den Besitzer des Zertifikats anzupassen. Nach dem das nun auch dem User systemd-journal-gateway gehört startet der Dienst ohne Probleme. Allerdings hilft das nur bis zum nächsten Fehler ... Eine Anfrage via Browser an den Journal e.g. https://192.168.2.200:19532 Zeigt im Browser (FF) dann den Fehler: PR_END_OF_FILE_ERROR Das hat wohl irgendwas mit nicht passenden Cipher Suites zu tun. der Dienst selber behauptet aber: "Request malformed. Your HTTP request was syntactically incorrect." Andere Browser haben andere Meldungen, aber funktionieren tut das nirgendwo :/ Das scheint alles nur insoweit zu laufen/getestet worden zu sein, als das es beim Kompilieren keine schweren Fehler wirft ... Schade, dieses Journal hatte was ... nur blöd das es so 'ne Totgeburt ist. Bernd -- Die normative Kraft des Faktischen behindert die Entwicklung zum Besseren.
Sorry, nehme alles zurück ... Am 23.05.21 um 15:10 schrieb Bernd Nachtigall:
Hallo Ulf,
Am 22.05.21 um 13:57 schrieb Ulf Volmer:
On 21.05.21 17:43, Bernd Nachtigall wrote:
Ich habe via 'systemctl edit systemd-journal-gatewayd.service' eine Erweiterung der Unit angelegt in der steht: [Service] ExecStart= ExecStart=/usr/lib/systemd/systemd-journal-gatewayd --cert=/etc/ssl/server/log.crt --key=/etc/ssl/private/log.key
cert und key sind im PEM-Format.
Wenn ich das Gateway nun starte und mit systemctl status nach dessen Befinden schaue, sehe ich die Meldung "Failed to read key file: Permission denied" (und https klappt natürlich nicht).
Die beiden Files haben die Rechte 400 und gehören systemd-journal-gateway.
Was sagt
ls -ld /etc/ssl/private ?
Na ja, der Ordner gehört natürlich root. Aber deine Antwort hat mich einen Schritt weiter gebracht. Obwohl in der Meldung von 'Key-File' die Rede war hat es geholfen auch den Besitzer des Zertifikats anzupassen. Nach dem das nun auch dem User systemd-journal-gateway gehört startet der Dienst ohne Probleme.
Allerdings hilft das nur bis zum nächsten Fehler ...
Eine Anfrage via Browser an den Journal e.g. https://192.168.2.200:19532 Zeigt im Browser (FF) dann den Fehler: PR_END_OF_FILE_ERROR Das hat wohl irgendwas mit nicht passenden Cipher Suites zu tun. der Dienst selber behauptet aber: "Request malformed. Your HTTP request was syntactically incorrect." Andere Browser haben andere Meldungen, aber funktionieren tut das nirgendwo :/
Doch tut es ... man darf dann nur nicht vergessen den Dienst wieder MIT https in Betrieb zu nehmen. Solange die Zeile noch auskommentiert ist wird es nicht klappen =8-O OK, damit kann ich mich den nächsten Problemen zuwenden ... ;-) Schöne Pfingsten! Bernd -- Die normative Kraft des Faktischen behindert die Entwicklung zum Besseren.
participants (2)
-
Bernd Nachtigall
-
Ulf Volmer