Mittlerweile denke ich, dass es evtl ein Rechteproblem sein könnte, da das cacert nicht heruntergeladen wird aber vorhanden ist?!
Ein ls -l wird das zeigen, aber das glaube ich nicht, da er ja das eigentliche Cert nutzt, nur das Intermediate nicht. Im Bundle sind ja beide, wenn er’s nicht lesen könnte würde er auch nicht das eigentliche Cert zeigen können.
Aha, das andere Problem habe ich gefunden:
root@server:/etc/cups/ssl# l
insgesamt 8
lrwxrwxrwx 1 root root 36 Feb 17 15:01 server.crt -> /etc/linuxmuster/ssl/server.cert.pem
-rw-r--r-- 1 root root 1363 Feb 21 09:13 server.fsmw.lan.crt
-rw-r--r-- 1 root root 1679 Feb 21 09:13 server.fsmw.lan.key
lrwxrwxrwx 1 root root 35 Feb 17 15:01 server.key -> /etc/linuxmuster/ssl/server.key.pem
Da werden also die falschen Symlinks erzeugt nehme ich an. Ich habe das mal korrigiert:
lrwxrwxrwx 1 root root 36 Feb 21 15:05 server.fsmw.lan.crt -> /etc/linuxmuster/ssl/server.cert.pem
lrwxrwxrwx 1 root root 35 Feb 21 15:05 server.fsmw.lan.key -> /etc/linuxmuster/ssl/server.key.pem
und nun ist es korrekt (also mit meinem self-signed). Cups scheint die Zertifikate nach CN zu ziehen und da stimmt dann server.* einfach nicht. Komisch sind nur die Zugriffszeiten für die Dateien - als ob die Dateien mit dem korrekten CN später erzeugt werden durch irgendeinen Lauf… Vorsicht ist geboten, dass der Lauf echte Zertifikate nicht überschreibt (die ssh Hostkeys werden ja auch einfach wahllos überschrieben, wenn man linuxmuster-prepare laufen lässt).
-rw-r--r-- 1 root ssl-cert 1648 Feb 20 17:44 cacert.crt
-rw-r--r-- 1 root ssl-cert 1648 Feb 20 17:44 cacert.pemDas sollte jeder lesen dürfen – wenn es das nicht ist, muss es offenbar das falsche cert sein??
Ich hatte es am Anfang des Threads schon mal gepostet und dann wieder gelöscht, da ich mir anfangs keinen Reim darauf machen konnte:
Ob die einzelnen Zertifikate im chain file wirklich zusammenpassen, können Sie mit OpenSSL überprüfen …
Hier steht, wie man es überprüfen kann:
Das passt alles:
openssl x509 -in server.cert.pem -noout -issuer_hash
stimmt überein mit
openssl x509 -in cacert.pem -noout -hash
und genauso simmen:
openssl x509 -in cacert.pem -noout -issuer_hash
und
openssl x509 -in /etc/ssl/certs/DST_Root_CA_X3.pem -noout -hash
überein.
Die Kette ist also ok – trotzdem gibt’s weiterhin den Fehler.
Nun, zuallererst muss der CN passen, also (vom root aufwärts):
2: Signature Trust Co., CN = DST Root CA X3 ist „self signed“ und als generell vertrauenswürdig im browser (oder openssl) vermerkt,
1: Digital Signature Trust Co., CN = DST Root CA X3 vertraut s:C = US, O = Let’s Encrypt, CN = Let’s Encrypt Authority X3,
0: s:C = US, O = Let’s Encrypt, CN = Let’s Encrypt Authority X3 vertraut s:CN = server…
Das ist das erste, was geprüft wird. Danach kommt erst die Sache mit den hashes. Aber da sind wir noch nicht. Es fehlt bereits die Stufe, von 2 zu 0 zu kommen. DST (root c in 2) → LE (cert in 0) ist gebrochen. Das geht nur mit 1 DST → LE. Das fehlt. Nur warum? Intermediate Certs sind jung, es könnte sein, dass die beiden das nicht können? Gibt es bereits eine Installation mit einem Intermediate?
Wen meinst du mit „die beiden“?
Es ist ja egal, ob ich es vom Client aus auf Port 443 (ajenti) oder 636 (samba/AD) versuche: In beiden Fällen erscheint die gleiche Meldung, obwohl es unterschiedliche Konfigurationsfiles sind: Bei ajenti wird auf das bundle zugegriffen, während es beim AD die einzelnen Files sind. Ich hatte gehofft, dass es wenigstens in einem der beiden Fälle klappt?
… was ich gerade sehe: Auf dem linux-Client steht in der /etc/samba/smb.conf der Eintrag: tls cafile = /var/lib/samba/private/tls/linuxmuster.meine-domain.de.pem
… das habe ich natürlich nicht ersetzt. Andererseits funktioniert es ja auch nicht von einem anderen Client.
… da die Ideen ausgehen noch eine ganz doofe Frage:
dürfen in der bundle.pem bzw fullchain.pem Leerzeilen auftauchen wie
...Yo4ug=
-----END CERTIFICATE-----
<< hier !
-----BEGIN CERTIFICATE-----
MIIE...oder ist das verboten? (Das habe ich nicht selbst eingefügt sondern das wurde von der OPNSense FW so ausgeliefert…)
Könnte nochmal jemand bei sich in die Datei
/etc/linuxmuster/ssl/server.cert.bundle.pem und die ursprüngliche Reihenfolge der certs und des Keys nennen.
ajenti und samba.
Ja, der sucht diese —BEGIN und END Kennungen.
-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
Also erst Key, dann Cert. Ich glaube ich hatte das andersherum, sorry. Das könnte man nochmal versuchen umzudrehen.
Erledigt – Im Moment habe ich den Verdacht, dass ich die LE-certs, die das OPNSense-Plugin erzeugt hat, aus irgendwelchen Gründen nicht fehlerfrei weiterverwenden kann … Warum es scheitert, ist mir zwar nicht klar aber eine bessere Erklärung habe ich auch nicht.
Die Lösung ist einfacher als gedacht …
Ich habe unter /etc/samba/smb.conf den Eintrag
#tls certfile = /etc/linuxmuster/ssl/server.cert.pem
getauscht gegen diesen:
tls certfile = /etc/linuxmuster/ssl/fullchain.pem
Danach wurde die Chain vom Client aus sofort akzeptiert!
Bleibt natürlich die Frage, ob ajenti mit dem intermediate-cert auch klar kommt? Das müsste @Arnaud wissen, oder?
Übrigens @mdt: Die Sache mit cups ist hier auch so – seltsam.
Hi Michael,
Ja, das weiss er :
cat /PATH/ZUR/privkey.pem > mycert.pem
cat /PATH/ZUR/fullchain.pem >> mycert.pem
Und dann /PATH/ZUR/mycert.pem in /etc/ajenti/config.yml eintragen, und die WebUi neu starten.
Gruß
Arnaud
Also kommt der Key doch nach oben?? Das stand in der Anleitung, die oben verlinkt ist, aber anders. Da hieß es, dass der Key immer ans Ende gehört…???
Das macht nichts für Ajenti : Python liest die Datei und extrahiert die Daten ( Privkey, CA, usw … ), egal wie die Reihefolge ist.
Gruß
Arnaud
Funktioniert leider nicht … es bleibt hier bei
Verify return code: 21 (unable to verify the first certificate)
Auf Port 636 ist die Meldung jetzt -wie gesagt- weg.
Ja, es stimmt : wir arbeiten, du und ich, in verschiedene Umgebungen.
Ich habe das SSL-Modul in Ajenti in Dezember komplett neu geschrieben. Die Version von Ajenti, die diese Änderungen enthält, ist 2.1.33, und du hast die 2.1.32.
Mit der 2.1.33 habe ich nicht mehr dieses Problem, aber die WebUi soll noch angepasst werden ( und getestet sein ), um ein Upgrade von Ajenti durchzuführen.
Im Kurz : es kommt bald, aber bitte NICHT Ajenti upgraden, ansonstens kann es zur Probleme führen.
Gruß
Arnaud
Hallo Arnaud.
Ok – aber gut zu wissen, dass das Problem gelöst ist. Der Zugriff über den Browser
klappt ja (seltsamerweise) trotzdem. Da wird immer ein gültiges Zertifikat angezeigt.
Schöne Grüße,
Michael
Ja, das cups setup ist kaputt, das Zertifikat ist auch anders (s:C = DE, CN = server.lmn.lan, O = server.lmn.lan, OU = Unknown, ST = Unknown, L = Unknown) und cups akzeptiert das andre nicht (ich hatte mich verlesen, als ich oben Erfolg meldete, es geht nicht).
… hatte mich schon gewundert. Hier wurden die files unter cups auch neu angelegt. Ich meine, dass sie nach einem service cups restart wieder da waren??
Um das nochmal aufzugreifen:
Momentan ist ajenti 33 im Linuxmuster-testing Zweig. Ich stecke da nicht so tief drin wie Arnaud, aber das könntest du jetzt sicherlich ausprobieren.
Hallo Andreas,
Um das nochmal aufzugreifen:
Momentan ist ajenti 33 im Linuxmuster-testing Zweig. Ich stecke da nicht
so tief drin wie Arnaud, aber das könntest du jetzt sicherlich ausprobieren.
wie bekomme ich den raus, welche ajenti Version auf meinem Server läuft?
LG
Holger
dpkg -l |grep webui
(die 33 verstehe ich aber auch nicht – muss es nicht .116. heißen?
https://archive.linuxmuster.net/lmn7-testing/ )
Ihr missversteht mich hier ein bisschen.
Die .116 installiert Ajenti33 mit.
Ajenti Version kannst du dir mit pip freeze | grep aj
ausgeben lassen.
Hier sollte aber nie manuell aktualisiert werden, das übernehmen alles wir über das Linuxmuster Paket.