# Frage zu Zertifikaten / SSL / Fehlermeldung bei openssl **URL:** \ **Category:** Server v7\ **Created:** [18. Februar 2020 um 15:08 UTC](https://ask.linuxmuster.net/t/frage-zu-zertifikaten-ssl-fehlermeldung-bei-openssl/4849 "2020-02-18T15:08:24Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![Michael](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/michael/32/59_2.png) [@Michael](https://ask.linuxmuster.net/u/Michael)\ **Post date:** [21. Februar 2020 um 13:54 UTC](https://ask.linuxmuster.net/t/frage-zu-zertifikaten-ssl-fehlermeldung-bei-openssl/4849/21 "2020-02-21T13:54:50Z")
Mittlerweile denke ich, dass es evtl ein Rechteproblem sein könnte, da das cacert nicht heruntergeladen wird aber vorhanden ist?! ---
**Author:** ![mdt](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/mdt/32/1888_2.png) [@mdt](https://ask.linuxmuster.net/u/mdt)\ **Post date:** [21. Februar 2020 um 14:01 UTC](https://ask.linuxmuster.net/t/frage-zu-zertifikaten-ssl-fehlermeldung-bei-openssl/4849/22 "2020-02-21T14:01:51Z")
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: ```auto 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: ```auto 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). ---
**Author:** ![Michael](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/michael/32/59_2.png) [@Michael](https://ask.linuxmuster.net/u/Michael)\ **Post date:** [21. Februar 2020 um 14:13 UTC](https://ask.linuxmuster.net/t/frage-zu-zertifikaten-ssl-fehlermeldung-bei-openssl/4849/23 "2020-02-21T14:13:19Z")
```auto -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.pem ``` Das 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,](https://doku.tid.dfn.de/de:certificates#einrichtung_der_vollstaendigen_zertifikatskette_auf_dem_webserver) 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. ---
**Author:** ![mdt](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/mdt/32/1888_2.png) [@mdt](https://ask.linuxmuster.net/u/mdt)\ **Post date:** [21. Februar 2020 um 14:19 UTC](https://ask.linuxmuster.net/t/frage-zu-zertifikaten-ssl-fehlermeldung-bei-openssl/4849/24 "2020-02-21T14:19:27Z")
> [@Michael](#): > > einzelnen Zertifikate im chain file wirklich zusammenpassen 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? ---
**Author:** ![Michael](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/michael/32/59_2.png) [@Michael](https://ask.linuxmuster.net/u/Michael)\ **Post date:** [21. Februar 2020 um 14:28 UTC](https://ask.linuxmuster.net/t/frage-zu-zertifikaten-ssl-fehlermeldung-bei-openssl/4849/25 "2020-02-21T14:28:34Z")
> [@mdt](#): > > Intermediate Certs sind jung, es könnte sein, dass die beiden das nicht können? 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 ```auto ...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. ---
**Author:** ![mdt](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/mdt/32/1888_2.png) [@mdt](https://ask.linuxmuster.net/u/mdt)\ **Post date:** [21. Februar 2020 um 16:35 UTC](https://ask.linuxmuster.net/t/frage-zu-zertifikaten-ssl-fehlermeldung-bei-openssl/4849/26 "2020-02-21T16:35:43Z")
> [@Michael](#): > > Wen meinst du mit „die beiden“? ajenti und samba. > [@Michael](#): > > dürfen in der bundle.pem bzw fullchain.pem Leerzeilen auftauchen Ja, der sucht diese —BEGIN und END Kennungen. > [@Michael](#): > > die **ursprüngliche** Reihenfolge ```auto -----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. ---
**Author:** ![Michael](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/michael/32/59_2.png) [@Michael](https://ask.linuxmuster.net/u/Michael)\ **Post date:** [21. Februar 2020 um 16:41 UTC](https://ask.linuxmuster.net/t/frage-zu-zertifikaten-ssl-fehlermeldung-bei-openssl/4849/27 "2020-02-21T16:41:06Z")
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. ---
**Author:** ![Michael](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/michael/32/59_2.png) [@Michael](https://ask.linuxmuster.net/u/Michael)\ **Post date:** [21. Februar 2020 um 20:09 UTC](https://ask.linuxmuster.net/t/frage-zu-zertifikaten-ssl-fehlermeldung-bei-openssl/4849/28 "2020-02-21T20:09:42Z")
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. ---
**Author:** ![Arnaud](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/arnaud/32/28_2.png) [@Arnaud](https://ask.linuxmuster.net/u/Arnaud)\ **Post date:** [21. Februar 2020 um 21:45 UTC](https://ask.linuxmuster.net/t/frage-zu-zertifikaten-ssl-fehlermeldung-bei-openssl/4849/29 "2020-02-21T21:45:26Z")
Hi Michael, > [@Michael](#): > > Bleibt natürlich die Frage, ob ajenti mit dem intermediate-cert auch klar kommt? Das müsste @Arnaud wissen, oder? 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 ---
**Author:** ![Michael](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/michael/32/59_2.png) [@Michael](https://ask.linuxmuster.net/u/Michael)\ **Post date:** [21. Februar 2020 um 22:01 UTC](https://ask.linuxmuster.net/t/frage-zu-zertifikaten-ssl-fehlermeldung-bei-openssl/4849/30 "2020-02-21T22:01:49Z")
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…??? ---
**Author:** ![Arnaud](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/arnaud/32/28_2.png) [@Arnaud](https://ask.linuxmuster.net/u/Arnaud)\ **Post date:** [21. Februar 2020 um 22:10 UTC](https://ask.linuxmuster.net/t/frage-zu-zertifikaten-ssl-fehlermeldung-bei-openssl/4849/31 "2020-02-21T22:10:14Z")
Das macht nichts für Ajenti : Python liest die Datei und extrahiert die Daten ( Privkey, CA, usw … ), egal wie die Reihefolge ist. Gruß Arnaud ---
**Author:** ![Michael](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/michael/32/59_2.png) [@Michael](https://ask.linuxmuster.net/u/Michael)\ **Post date:** [21. Februar 2020 um 22:16 UTC](https://ask.linuxmuster.net/t/frage-zu-zertifikaten-ssl-fehlermeldung-bei-openssl/4849/32 "2020-02-21T22:16:15Z")
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. ---
**Author:** ![Arnaud](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/arnaud/32/28_2.png) [@Arnaud](https://ask.linuxmuster.net/u/Arnaud)\ **Post date:** [21. Februar 2020 um 22:31 UTC](https://ask.linuxmuster.net/t/frage-zu-zertifikaten-ssl-fehlermeldung-bei-openssl/4849/33 "2020-02-21T22:31:22Z")
> [@Michael](#): > > Funktioniert leider nicht … es bleibt hier bei > `Verify return code: 21 (unable to verify the first certificate)` 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 ---
**Author:** ![Michael](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/michael/32/59_2.png) [@Michael](https://ask.linuxmuster.net/u/Michael)\ **Post date:** [21. Februar 2020 um 22:33 UTC](https://ask.linuxmuster.net/t/frage-zu-zertifikaten-ssl-fehlermeldung-bei-openssl/4849/34 "2020-02-21T22:33:10Z")
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 ---
**Author:** ![mdt](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/mdt/32/1888_2.png) [@mdt](https://ask.linuxmuster.net/u/mdt)\ **Post date:** [21. Februar 2020 um 22:47 UTC](https://ask.linuxmuster.net/t/frage-zu-zertifikaten-ssl-fehlermeldung-bei-openssl/4849/35 "2020-02-21T22:47:00Z")
> [@Michael](#): > > Die Sache mit cups ist hier auch so – seltsam 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_). ---
**Author:** ![Michael](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/michael/32/59_2.png) [@Michael](https://ask.linuxmuster.net/u/Michael)\ **Post date:** [21. Februar 2020 um 22:48 UTC](https://ask.linuxmuster.net/t/frage-zu-zertifikaten-ssl-fehlermeldung-bei-openssl/4849/36 "2020-02-21T22:48:07Z")
… 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?? ---
**Author:** ![Till](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/till/32/970_2.png) [@Till](https://ask.linuxmuster.net/u/Till)\ **Post date:** [25. Februar 2020 um 10:27 UTC](https://ask.linuxmuster.net/t/frage-zu-zertifikaten-ssl-fehlermeldung-bei-openssl/4849/37 "2020-02-25T10:27:41Z")
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. ---
**Author:** ![baumhof](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/baumhof/32/1504_2.png) [@baumhof](https://ask.linuxmuster.net/u/baumhof)\ **Post date:** [25. Februar 2020 um 10:49 UTC](https://ask.linuxmuster.net/t/frage-zu-zertifikaten-ssl-fehlermeldung-bei-openssl/4849/38 "2020-02-25T10:49:07Z")
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 ---
**Author:** ![Michael](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/michael/32/59_2.png) [@Michael](https://ask.linuxmuster.net/u/Michael)\ **Post date:** [25. Februar 2020 um 10:53 UTC](https://ask.linuxmuster.net/t/frage-zu-zertifikaten-ssl-fehlermeldung-bei-openssl/4849/39 "2020-02-25T10:53:52Z")
`dpkg -l |grep webui` (die 33 verstehe ich aber auch nicht – muss es nicht .116. heißen? [https://archive.linuxmuster.net/lmn7-testing/](https://archive.linuxmuster.net/lmn7-testing/) ) ---
**Author:** ![Till](https://ask.linuxmuster.net/user_avatar/ask.linuxmuster.net/till/32/970_2.png) [@Till](https://ask.linuxmuster.net/u/Till)\ **Post date:** [25. Februar 2020 um 10:59 UTC](https://ask.linuxmuster.net/t/frage-zu-zertifikaten-ssl-fehlermeldung-bei-openssl/4849/40 "2020-02-25T10:59:37Z")
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. [Vorherige Seite](https://ask.linuxmuster.net/t/frage-zu-zertifikaten-ssl-fehlermeldung-bei-openssl/4849.md?page=1) [Nächste Seite](https://ask.linuxmuster.net/t/frage-zu-zertifikaten-ssl-fehlermeldung-bei-openssl/4849.md?page=3)