Add a New Comment (Rich Markup)
Hallo Werner, das ist schon alles richtig was du da schreibst. Nun geht es hier nicht um irgend ein Programm, sondern um davfs2 von dir. Kann denn davfs2 über eine Zertifikatskette ein Unterzertifikat überprüfen, also eine ganze Kette? Bei Raspian ist der CA-Speicher unter /usr/share/ca-certificates/mozilla Dort ist auch das Zertifikat der CA drin die Let's Encrypt zertifiziert hat (DST). Das mit dem Workaround ist soweit schon eine Idee. Allerdings brauche ich dann nicht auf eine öffentliche Zertifikatsstruktur zurückgreifen, sondern kann dann gleich auf eine eigene PKI nehmen. Der Sinn, das über eine öffentliche Zertifikatsstruktur zu machen, besteht darin dass dann nicht bei jedem Client nacharbeiten muss in Form von neuem Zertifkat einspielen. Das DST-Zertifikat haben die meisten Linux-Distributionen im CA-Paket enthalten. Bei Let's Encrypt muss das Zertifikat alle 90 Tage verlängert werden, sprich es gibt mehrmals im Jahr neue Zertifikate. Ein Root-Zertifikat von Let's Encrpyt habe ich unter /usr/share/ca-certificates/mozilla nicht gefunden, aber das von DST die eben Let's Encrypt zertifiziert haben. Mit diesem DST-Cert sollten sich alle 90-Tage-Zertifikate prüfen lassen. Mir ist nicht klar warum es ein Problem ist dass Let's Encrypt das Root-CA geändert hat. Wichtig ist doch nur dass die Kette passt. Da das Let's Encrypt CA nicht im erwähten Speicher ist, erfolgt die Verifizierung über das DST-Certifikat war meine Idee. Wie muss so ein Root-Zertifikat aussehen damit es von davfs2 genutzt werden kann (bestimmter Dateinamen, bestimmtes Format, usw.)? Kann davfs2 vielleicht nur eine Stufe bei Cert-Ketten? Wie kann ich bei davfs2 mehr Informationen ausgeben lassen um zu sehen warum es be meinem Cert nicht funktioniert, also ein detailierteres Logging? Vielen Dank schonmal für deine Hilfe. Martin
comment #1:
> Let's Encrypt changed the Root-CA some time ago what led to various troubles. > On many systems Browsers don't use the system CA-store but maintain their own store. So what works with a browser will not necessarily work with other applictaions. > > Possible reasons: > * the CA-certificate is in the store of the browser but not in the one used by the TLS-library > * the server sends the wrong certificate chain. > > Instead of trying to resolve the certificate mess created by Let's Encrypt it might be useful in this case to use some workaround untill Let's Encrypt and your OS-vendor resolved the problem. > > The workaround: > Use option trust_server_cert (see "man davfs2.conf" for details). You will have to update the certificate file whenever the server changes the certificate. > > Werner >
Let's Encrypt changed the Root-CA some time ago what led to various troubles. On many systems Browsers don't use the system CA-store but maintain their own store. So what works with a browser will not necessarily work with other applictaions. Possible reasons:
Instead of trying to resolve the certificate mess created by Let's Encrypt it might be useful in this case to use some workaround untill Let's Encrypt and your OS-vendor resolved the problem. The workaround: Use option trust_server_cert (see "man davfs2.conf" for details). You will have to update the certificate file whenever the server changes the certificate. Werner
Hallo Werner, ich habe auf meinem rPI4 eine Nextcloud-Instanz am laufen die aus dem Internet erreichbar ist. Da sich die die öffentliche IP ändern kann (Vodafone-Kabelanschluss, IP4-only, rPI hinter FritBox), ist der rPI und damit Nextcloud über einen DDNS (irgendwas.dyndns.org) erreichbar. Die Nextcloud-Instanz hat ein Let’s Encrypt Zertifikat. Alle getesteten Browser (Firefox, Chrome, Edge) akzeptieren das Cert (Zugriff auf die Weboberfläche von Nextcloud und auch bei Zugriff auf die WebDav-Freigabe). Nun möchte ich diese Nextcloud-Instanz mit davfs2, also mount.davfs , mounten. Allerdings wird ein automatischer Verbindungsaufbau abgelehnt (aus Journald): mount.davfs[6904]: ssl: Match common name 'irgendwas.myftp.org' against 'irgendwas.myftp.org' mount.davfs[6904]: Identity match for 'irgendwas.myftp.org': good mount.davfs[6904]: wir trauen dem Zertifikat nicht mount.davfs[6904]: Aussteller des Zertifikats: Let's Encrypt, US mount.davfs[6904]: Inhaber des Zertifikats: irgendwas.myftp.org mount.davfs[6904]: Name: irgendwas.myftp.org mount.davfs[6904]: SSL certificate checks failed: Server certificate verification failed: issuer is not trusted Ich habe in der davfs2.conf nichts vom Standard abweichend eingetragen, sprich auch kein eigenes Zertifikat oder einen Cert-Pfad hinterlegt. Somit sollte davfs2 den System-Zertifikatsspeicher nutzen. Dort ist auch ein Root-Zertifikat von DST enthalten die Let's Encrypt zertifiziert haben. Dieses Root-Zertifikat müsste also auch das von mir verifizieren (macht es in Browsern auch). Warum traut davfs2 meinem Zertifikat nicht? Egal ob ich mit davfs2 über die gleiche Maschine, auf der Nextcloud läuft, oder einer anderen Maschine im privaten Netz, oder aus dem Internet mit davfs2 zugreife, so wird meinem Zertifikat nicht getraut. Das Cert ist natürlich noch gültig. Das Cert ist auf den CommonName ausgestellt auch auf die Nextcloud zugegriffen wird (irgendwas.myftp.org). In der php-Config für die Nextcloud ist bei den TrustedDomains neben anderen auch irgendwas.myftp.org eingetragen. Was mache ich falsch? Ich habe die Version 1.6.0 von davfs2. Vielen Dank schonmal für deine Hilfe.
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach Files: Comment:
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Only logged-in users can vote.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Follow 3 latest changes.
Copyright © 2023 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.11