Frage zu Zertifikaten / SSL / Fehlermeldung bei openssl

[Michael]

Ok – an dieser Stelle war ich vor einiger Zeit schon mal. Was ist besser: die certs einfach umzubenennen und die Einträge in den .conf-Dateien so zu lassen oder umgekehrt? ich denke fast, dass der erste Weg besser ist, da man dann keine Stelle übersieht, oder?

[mdt]

Ja, vermutlich, dann stimmen die Namen auch. Du kannst von dem Verzeichnis ja vorher eine Sicherheitskopie machen, dann kommst du schnell zurück. Du musst allerdings auch die Bundle-Datei erzeugen.

Oh, und die Konfiguration von Samba braucht das andre Cert (LE), das würde ich wohl da drin umstellen.

[Michael]

@mdt

Oh, und die Konfiguration von Samba braucht das andre Cert (LE), das würde ich wohl da drin umstellen.

Wie meinst Du das?

[Michael]

Hi.
Also ich habe vorhin nochmal auf den Server und auf den Host geschaut, der die LE-Zertifikate anfordert (das macht hier direkt die OPNSense-Firewall über das LE-Plugin). Die unterschiedliche Benennung der Dateien hatten wir ja kürzlich schon diskutiert … ich blicke leider trotzdem noch nicht ganz durch. so dass ich nochmal beides gegenüberstelle:

Auf dem Server gibt es (wie schon von dir zitiert):

-rw-r--r-- 1 root root     2822 Feb 17 15:04 server.cert.bundle.pem
-rw-r----- 1 root ssl-cert 1143 Feb 17 15:01 server.cert.pem
-rw-r----- 1 root ssl-cert  976 Feb 17 15:01 server.csr
-rw------- 1 root ssl-cert 1679 Feb 17 15:01 server.key.pem

Daneben gibt es auf dem Server aber auch noch:

-rw-r----- 1 root ssl-cert 1648 Feb 19 12:54 cacert.crt
-rw-r----- 1 root ssl-cert 1648 Feb 19 12:54 cacert.pem
-rw-r----- 1 root ssl-cert 1812 Sep 14 16:28 cacert.pem.b64
-rw-r----- 1 root ssl-cert   41 Sep 14 16:28 cacert.srl
-rw------- 1 root ssl-cert 1766 Sep 14 16:28 cakey.pem

Auf der anderen Seite, sieht das gleiche Verzeichnis so aus:

-rwxr-x---  1 root  wheel  1648 Jan 29 10:08 ca.cer*
-rwxr-x---  1 root  wheel  3933 Jan 29 10:08 fullchain.cer*
-rwxr-x---  1 root  wheel  2285 Jan 29 10:08 server.linuxmuster.meine-domain.de.cer*
-rwxr-x---  1 root  wheel  1700 Jan 29 10:08 server.linuxmuster.meine-domain.de.csr*
-rwxr-x---  1 root  wheel  3243 Nov 21 11:32 server.linuxmuster.meine-domain.de.key*

Ich habe also alles auf den Server nach /etc/linuxmuster/ssl rüberkopiert und umbenannt, und zwar:

server.linuxmuster.meine-domain.de.cer --> server.cert.pem
server.linuxmuster.meine-domain.de.csr --> server.csr
server.linuxmuster.meine-domain.de.key --> server.key.pem

(bis hierhin eindeutig, meine ich)
Aber dann:

ca.cer --> cacert.crt (??)
ca.cer --> cacert.pem (??)

Wenn ich jetzt den Befehl openssl s_client -connect server:443 loslasse, erhalte ich leider weiterhin nur:

---
Certificate chain
 0 s:CN = server.linuxmuster.meine-domain.de
   i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
---

… aber die o.g. verify error bleiben.
Leider ist mir die Rolle der ca-Zertifikate sowie der fullchain (im Vergleich zum bundle) nicht ganz klar.

Hier ein gescheites HowTo, wo mal die Basics vernünftig erklärt werden. Natürlich gibt’s was offizielles – das ist aber über 300 Seiten stark und liest sich nicht mal kurz nebenbei.

Wie gesagt: openssl s_client -connect firewall:443 liefert die Fehler nicht, so dass der Fehler auf der Serverseite liegen muss.
@mdt: Blickst du noch durch?

Schönen Gruß,
Michael

[mdt]

@Michael

Blickst du noch durch

Ich versuch’s mal: Die Full-Chain plus der (Private-)Key ist das bundle. Da du https testest und das bundle nicht erneuert hast, das vom https-Dienst genutzt wird, ist das Verhalten erklärlich.

Ich denke ein

cat fullchain.cer server.linuxmuster.meine-domain.de.key > server.cert.bundle.pem

plus Neustart des https-Dienstes macht, was du brauchst. Das Full ist ca + server (1648 + 2285 = 3933 passt).

Ja, cacert.crt und cacert.pem sind identisch (schau diff cacert.crt cacert.pem zeigt keine Unterschiede - jedenfalls bei mir). Also ca.cer auf beide kopieren (schau dir das ca.cer an mit openssl x509 -noout -in "ca.cer" -subject, da sollte dann ja was mit LE auftauchen).

Dass die FW korrekt ist, liegt daran, dass du ja das LE-Script da laufen lässt und das Script da alles richtig einrichtet. Aber eben nicht für den Server (der ja auch die andren Zertifikate bekommt).

[Michael]

Hi.
Ok, ich habe den cat Befehl ausprobiert. Das bundle ist jetzt 7175 groß.
Danach systemctl restart linuxmuster-webui – der Zugriff auf die WebUI über https://server…:443 liefert weiterhin ein gültiges LE-Zertifikat aber die Verbindung via openssl liefert weiterhin den gleichen Fehler.

@mdt

Aber eben nicht für den Server (der ja auch die andren Zertifikate bekommt).

Das LE-Plugin erstellt die Zertifitkate für den Server im grünen Netz.

schau dir das ca.cer an mit openssl

Das funktioniert und liefert:
subject=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

Merkwürdig finde ich aber trotzdem, dass ich trotz des neuen bundles immernoch dies erhalte:

openssl s_client -showcerts -connect server:443
CONNECTED(00000005)
depth=0 CN = server.linuxmuster.meine-domain.de
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = server.linuxmuster.meine-domain.de
verify error:num=21:unable to verify the first certificate
verify return:1
---

vgl auch hier: Five Essential OpenSSL Troubleshooting Commands - MovingPackets.net
---> This can be fixed by adding the -CAfile option ... Vielleicht ist es das?
Immerhin Licht am Ende des Tunnels:
openssl verify -CAfile ./cacert.pem server.cert.pem
server.cert.pem: OK
aber ohne die Option -CAfile bekomme ich:
error server.cert.pem: verification failed

Kann es sein, dass das cacert.pem global bekannt gemacht werden muss? Sowas hatten wir doch schon mal diskutiert – und zwar hier?!

(Ich denke, dass das Verhalten auch mit dem HAProxy (reverse Proxy) zusamenhängen könnte – bin aber nicht ganz sicher…)

Schönen Gruß,
Michael

[mdt]

@Michael

der Zugriff auf die WebUI über https://server…:443 liefert weiterhin ein gültiges LE-Zertifikat aber die Verbindung via openssl liefert weiterhin den gleichen Fehler.

Moment - das verstehe ich nicht. Das hattest du bislang nicht gesagt, dass für den Server etwas funktioniert. Ich hatte verstanden FW geht, Server nicht.

@Michael

das Verhalten auch mit dem HAProxy

Ich bin durch die Architektur von LM noch nicht ganz durchgestiegen. Im Grunde müssen alle Komponenten, die hinter der Domain SSL/TLS anbieten das Zertifikat mit dem gleichnamigen oder passenden Wildcard CN anbieten und eine Kette runter zu einem akzeptierten root-Zertifikat sonst wirds nix.

Der Hinweis mit dem CAfile gilt, wenn du ein eigenes root-CA nennen möchtest.

Du hast aber noch das Zertifikat, was du garnicht haben möchtest: Die self-signed Zertifikate. openssl sollte eben eine Chain anzeigen… die beruhen auf einem Zertifikat, das openssl kennt und dann brauchst du CAfile garnicht.

Ich vermute erstmal, dass da eine Komponente ist, die ein restart braucht oder auch eine Konfigurationsänderung.

Bei mir läuft unter :443 ein ajenti-panel, dass in /usr/local/bin installiert ist. Das hat die config in /etc/ajenti/config.yml, die sollte nach deiner Kopiererei passen, da dort certificate: /etc/linuxmuster/ssl/server.cert.bundle.pem referenziert wird.

Das Logfile ist in /var/log/ajenti/ajenti.log, vielleicht findest du da was?

[Michael]

Jetzt klappt’s … und im Nachhinein hätte ich mal besser schon im November 2019 direkt auf Dich gehört, als Du meintest:

@mdt

Prima!
Und nun alles von vorn mit dem offiziellen LE-Zertifikat!

Letztlich fehlte auf dem Server die gleiche Vorgehensweise wie damals mit dem self-signed-cert. Also hier nochmal die Vorgehensweise, die zum Ziel führt.
Eine kleine Ergänzung aber noch:
Ich habe unter
/usr/local/share/ca-certificates/ ein Verzeichnis server.linuxmuster.LE angelegt und dort einen Link erstellt:
linuxmuster-LE.crt -> /etc/linuxmuster/ssl/server.cert.pem
Anschließend dann update-ca-certificates und DANN funktioniert auch die Verbindung über openssl auf Port 443

Unter’m Strich ist es gar nicht soooooooo kompliziert, wenn man erstmal durchgestiegen ist, wie sich so eine trusted chain zusammensetzt. Da hat der Link von oben ordentlich geholfen…

Besten Dank mal wieder!
Michael

P.S.:

@mdt

Das hattest du bislang nicht gesagt, dass für den Server etwas funktioniert.

Doch – im allerersten Satz ganz oben…

Eine Sache musst du mir aber doch noch(mal) erklären: Wenn ich es nun von einem anderen Client aus versuche, erhalte ich erneut Verify return code: 21 (unable to verify the first certificate) … ?! Heißt das: die gleiche Prozedur auf jedem Client, der openssl verwenden will, von vorne??

[mdt]

@Michael

gar nicht soooooooo kompliziert

Sag’ ich doch!

@Michael

Wenn ich es nun von einem anderen Client aus versuche, erhalte ich erneut Verify return code: 21 (unable to verify the first certificate) … ?! Heißt das: die gleiche Prozedur auf jedem Client, der openssl verwenden will, von vorne

Nein. Das muß etwas anderes sein, denn der Server schickt ja das Zertifikat. Du hast auf dem Client openssl gegen den server gemacht, richtig? Das mit dem richtigen servernamen (domain), die auch CN in dem zertifikat ist, ja? Gibt er die Kette denn an? Oder ist es wieder dies eine Ding wo „CN = LINUXMUSTER.MEINE-DOMAIN.DE“ steht?

@Michael

im allerersten Satz ganz oben

Nicht ganz: da steht, dass Samba geht, denn der hat port 636.

[Michael]

@mdt

Du hast auf dem Client openssl gegen den server gemacht, richtig?

Ja – aber auch, wenn ich den kompletten FQDN server.linuxmuster.meine-domain.de wähle, kommt wieder genau wie zuvor:

```
openssl s_client -showcerts -connect server.linuxmuster.meine-domain.de:443
CONNECTED(00000005)
depth=0 CN = server.linuxmuster.meine-domain.de
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = server.linuxmuster.meine-domain.de
verify error:num=21:unable to verify the first certificate
verify return:1
---

Kann es damit zusammenhängen, dass ich vorher schon mit self-signed-certs herumexperimentiert hatte und das auf dem Client evtl schon mal akzeptiert wurde?

@mdt

Gibt er die Kette denn an?

Ich denke, dass die weiterhin zu kurz ist, oder?

---
Certificate chain
 0 s:CN = server.linuxmuster.meine-domain.de
   i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
---

Ist bei dir länger, oder?

@mdt

Nicht ganz: da steht, dass Samba geht, denn der hat port 636.

Noch höher: → „Ein Zugriff per https:// auf den Server bestätigt das.“

[Michael]

Ergänzend:

https://blog.pki.dfn.de/2014/10/skript-zum-testen-der-zertifikatkette-und-sslv3-faehigkeit-eines-servers/

[tjordan]

Hallo Michael,

relativ einfach: Das Zertifikat gilt nur für den FQDN als server.meine-doma.in nicht für den Kurznamen. Wenn du den Server mit dem FQDN abfragst, solltest du keinen Zertifikatsfehler bekommen.

Gruß

Thomas

Mit freundlichen Grüßen
Thomas Jordan
Technik


Innovative Datensysteme GmbH indasysLeitzstraße 4c

D-70469 Stuttgart

Telefon:

Telefax:

E-Mail:

Web:
+49 711 896659 193

+49 711 896659 149

Thomas.Jordan@indasys.de

www.indasys.de

Jetzt anmelden:

https://www.indasys.de/anmeldung-didacta-2020/

USID: DE199226070

HRB: 19846 AG Stuttgart

Geschäftsführer: Victor Ferreira, Dominik Appich

[Michael]

Hallo Thomas
Nein, daran liegt es aber leider nicht … erst wenn ich das intermediate cacert.pem unter /usr/local/share/ca-certificates verlinke und danach ein update-ca-certificates durchführe, funktioniert die Verbindung ohne die verfify-error-Meldung vom Client aus.
Die Chain ist dann aber auch weiterhin so kurz wie schon zuvor geschrieben

Eigentlich sollte es aber so sein, dass das intermediate-cert mit vom server heruntergeladen wird, oder?!

Die Datei server.cert.bundle.pem unter /etc/linuxmuster/ssl besteht übrigens aus dem eigenen cert, dem intermediate-cert und dem RSA Key – auch in der richtigen Reihenfolge und die WebUI wurde auch neu gestartet

Schönen Gruß,
Michael

[mdt]

@Michael

auf dem Client evtl schon mal akzeptiert wurde

Das war ja vermutlich im Browser. Der Browser hat mit OpenSSL nichts zu tun.

Ich bin nicht ganz sicher, dass ich verstehe von wo aus du welche Tests abfeuerst. Ich würde erstmal schauen, was in deinen Zertifikaten steht. Mach dich auf dem Server einmal:

cd /etc/linuxmuster/ssl; for n in *.crt* *.cert*; do echo -n $n; openssl x509 -noout -in $n -subject; done

Das gibt dir (bis auf bei dem Bundle und dem .b64) aus, was das subject der Zertifikate ist.

[mdt]

(Die Antwort kam per PN und die Ausgabe sah korrekt aus)

Dieser Befehl zeigt dir die Chains der Dienste auf dem Server, es sollte auf dem Server laufen:

for n in  443 464 631 636 3269 ; do echo $n; echo -n|openssl s_client -connect localhost:$n 2> /dev/null | sed -n '/^Certificate chain/,/^---$/p' ; done

Selbst bei mir, wo ich die Zertifikate nicht angefasst habe zeigt das eine Inkonsistenz. Wie siehts bei dir aus?

[mdt]

Port 631 sieht bei mir auch falsch aus. Das scheint noch ein Fehler im Gesamtsetup zu sein.

Certificate chain
 0 s:CN = server.....
   i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
---

Da fehlt das Intermediate-Certificate, es sollte so aussehen

Certificate chain
 0 s:CN = server.....
   i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
 1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
 2 s:O = Digital Signature Trust Co., CN = DST Root CA X3
   i:O = Digital Signature Trust Co., CN = DST Root CA X3

Also stimmt die Konfiguration noch nicht.

443 bedient ajenti, das in /etc/ajenti/config.yml konfiguriert wird unter „certificate“, da steht das Bundle. Ich verstehe nicht warum der das Intermediate nicht nutzt, wenn es im Bundle drin ist. Kann ajenti Intermediates?

636 bedient samba, das hat in smb.conf „tls *file“. Das Intermediate soll in cafile konfiguriert werden - das hast du ja. Selbe Frage wie oben…

[Michael]

Mittlerweile denke ich, dass es evtl ein Rechteproblem sein könnte, da das cacert nicht heruntergeladen wird aber vorhanden ist?!

[mdt]

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).

[Michael]

-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, 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.

[mdt]

@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?