[Problem] 7270v3 trunk -> davfs2: Server certificate verification failed: issuer is not trusted

[GNUisNotUnix]

Fehler:
-----------------------------------------------------------------------------------------------------
Mounting failed.
Server certificate verification failed: issuer is not trusted
mount: mounting https://dav.disk.alice.de on /var/tmp/alice failed: No such device
Starting DavFS2 ... failed.
-----------------------------------------------------------------------------------------------------
Root und Zwischenzertifikat -> /var/tmp/flash/davfs2/servercrt1.pem

Ich habe sogar das Zertifkat von dav.disk.alice.de und die Datei servercrt1.pem aus dem Router (über scp) in meinen Rechner kopiert und mit openssl bestätigt, dass die Zertifikate richtig sind:

$ cat servercrt1.pem
-----BEGIN CERTIFICATE-----
MIIEbDCCA1SgAwIBAgIQTV8sNAiyTCDNbVB+JE3J7DANBgkqhkiG9w0BAQUFADCB
qTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDHRoYXd0ZSwgSW5jLjEoMCYGA1UECxMf
Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjE4MDYGA1UECxMvKGMpIDIw
MDYgdGhhd3RlLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNV
BAMTFnRoYXd0ZSBQcmltYXJ5IFJvb3QgQ0EwHhcNMTAwMjA4MDAwMDAwWhcNMjAw
MjA3MjM1OTU5WjA8MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMVGhhd3RlLCBJbmMu
MRYwFAYDVQQDEw1UaGF3dGUgU1NMIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAmeSFW3ZJfS8F2MWsyMip09yY5tc0pi8M8iIm2KPJFEyPBaRF6BQM
WJAFGrfFwQalgK+7HUlrUjSIw1nn72vEJ0GMK2Yd0OCjl5gZNEtB1ZjVxwWtouTX
7QytT8G1sCH9PlBTssSQ0NQwZ2ya8Q50xMLciuiX/8mSrgGKVgqYMrAAI+yQGmDD
7bs6yw9jnw1EyVLhJZa/7VCViX9WFLG3YR0cB4w6LPf/gN45RdWvGtF42MdxaqMZ
pzJQIenyDqHGEwNESNFmqFJX1xG0k4vlmZ9d53hR5U32t1m0drUJN00GOBN6HAiY
XMRISstSoKn4sZ2Oe3mwIC88lqgRYke7EQIDAQABo4H7MIH4MDIGCCsGAQUFBwEB
BCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AudGhhd3RlLmNvbTASBgNVHRMB
Af8ECDAGAQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudGhhd3Rl
LmNvbS9UaGF3dGVQQ0EuY3JsMA4GA1UdDwEB/wQEAwIBBjAoBgNVHREEITAfpB0w
GzEZMBcGA1UEAxMQVmVyaVNpZ25NUEtJLTItOTAdBgNVHQ4EFgQUp6KDuzRFQD38
1TBPErk+oQGf9tswHwYDVR0jBBgwFoAUe1tFz6/Oy3r9MZIaarbzRutXSFAwDQYJ
KoZIhvcNAQEFBQADggEBAIAigOBsyJUW11cmh/NyNNvGclYnPtOW9i4lkaU+M5en
S+Uv+yV9Lwdh+m+DdExMU3IgpHrPUVFWgYiwbR82LMgrsYiZwf5Eq0hRfNjyRGQq
2HGn+xov+RmNNLIjv8RMVR2OROiqXZrdn/0Dx7okQ40tR0Tb9tiYyLL52u/tKVxp
EvrRI5YPv5wN8nlFUzeaVi/oVxBw9u6JDEmJmsEj9cIqzEHPIqtlbreUgm0vQF9Y
3uuVK6ZyaFIZkSqudZ1OkubK3lTqGKslPOZkpnkfJn1h7X3S5XFV2JMXfBQ4MDzf
huNMrUnjl1nOG5srztxl1Asoa06ERlFE9zMILViXIa4=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEIDCCAwigAwIBAgIQNE7VVyDV7exJ9C/ON9srbTANBgkqhkiG9w0BAQUFADCB
qTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDHRoYXd0ZSwgSW5jLjEoMCYGA1UECxMf
Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjE4MDYGA1UECxMvKGMpIDIw
MDYgdGhhd3RlLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNV
BAMTFnRoYXd0ZSBQcmltYXJ5IFJvb3QgQ0EwHhcNMDYxMTE3MDAwMDAwWhcNMzYw
NzE2MjM1OTU5WjCBqTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDHRoYXd0ZSwgSW5j
LjEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjE4MDYG
A1UECxMvKGMpIDIwMDYgdGhhd3RlLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNl
IG9ubHkxHzAdBgNVBAMTFnRoYXd0ZSBQcmltYXJ5IFJvb3QgQ0EwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsoPD7gFnUnMekz52hWXMJEEUMDSxuaPFs
W0hoSVk3/AszGcJ3f8wQLZU0HObrTQmnHNK4yZc2AreJ1CRfBsDMRJSUjQJib+ta
3RGNKJpchJAQeg29dGYvajig4tVUROsdB58Hum/u6f1OCyn1PoSgAfGcq/gcfomk
6KHYcWUNo1F77rzSImANuVud37r8UVsLr5iy6S7pBOhih94ryNdOwUxkHt3Ph1i6
Sk/KaAcdHJ1KxtUvkcx8cXIcxcBn6zL9yZJclNqFwJu/U30rCfSMnZEfl2pSy94J
NqR32HuHUETVPm4pafs5SSYeCaWAe0At6+gnhcn+Yf1+5nyXHdWdAgMBAAGjQjBA
MA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7W0XP
r87Lev0xkhpqtvNG61dIUDANBgkqhkiG9w0BAQUFAAOCAQEAeRHAS7ORtvzw6WfU
DW5FvlXok9LOAz/t2iWwHVfLHjp2oEzsUHboZHIMpKnxuIvW1oeEuzLlQRHAd9mz
YJ3rG9XRbkREqaYB7FViHXe4XI5ISXycO1cRrK1zN44veFyQaEfZYGDm/Ac9IiAX
xPcW6cTYcvnIc3zfFi8VqT79aie2oetaupgf1eNNZAqdE8hhuvU5HIe6uL17In/2
/qxAeeWsEG89jxt5dovEN7MhGITlNgDrYyCZuen+MwS7QcjBAvlEYyCegc5C09Y/
LHbTY5xZ3Y+m4Q6gLkH3LpVHz7z9M/P2C2F+fpErgUfCJzDupxBdN49cOSvkBPB7
jVaMaA==
-----END CERTIFICATE-----

$ cat cert.pem

-----BEGIN CERTIFICATE-----
MIID6zCCAtOgAwIBAgIQBv/XirMxAngRWIP02ayMHjANBgkqhkiG9w0BAQUFADA8
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMVGhhd3RlLCBJbmMuMRYwFAYDVQQDEw1U
aGF3dGUgU1NMIENBMB4XDTExMDEyNzAwMDAwMFoXDTEzMDIyNTIzNTk1OVowgYMx
CzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHFAdIYW1idXJn
MSgwJgYDVQQKFB9IYW5zZU5ldCBUZWxla29tbXVuaWthdGlvbiBHbWJIMQwwCgYD
VQQLFANJQVUxGDAWBgNVBAMUDyouZGlzay5hbGljZS5kZTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANYbVIqGxGoSPYt8j5JroG2ZFZp72mWd/GWUoP06
qfjioHJtOUTOtCokPUos36iMkvoTDceXzjnBzCRHv93uNx5OYAm3pSBot9lyalmR
mAsNdV7H5NZanaZmh5S1YATCyGzzTInekf8DPog+NcqO/JoWs0PWJNXgCdL8TxND
tAg0rhJT0Be8esAd/WhSJB+4S3sD9Lj86cUSjnNHdp6+o8w45k8EkqeaIBaJoTdo
O/kdKfnDSNeFFg0jsOTyrq+YRU3rf5Nr3pQW+AIm2GnkYp49mDqNiwyt9b3trgpD
ASqqM0WM1n+DZiqkncbzgkZL7dBzFrzxLnIGXCd8/IU/d0kCAwEAAaOBoDCBnTAM
BgNVHRMBAf8EAjAAMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9zdnItb3YtY3Js
LnRoYXd0ZS5jb20vVGhhd3RlT1YuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggr
BgEFBQcDAjAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3Nw
LnRoYXd0ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBACKRoafp0ydyGu9FVbk9tdeN
jXnm2UAiHZnNcieiiRIYYzeibBXWAhheso6DadBEnZ90iD7JYjbTkmgkrX5qjgN4
MMZa2gpcIxzvbkSxZqZHbp0gqwpSWEcotfgSKzZB7phbwh1fKGrizKTFhthUFm4A
Z7gj3+kGXVazgoctOuRc53rk7phtGgv0S7niY4jfgDSmbOqNyINx84tDVgiDJJfl
Ww1ttnLK3DhHzTn3hKJecddTPoIS7KzJp4EhEBSvXnlIiPoirTxwK855diQB3UMq
ieRkm5R6KYxxCajNZZOAIOQuqC3FFQxkPUpAD+6cwDJgxQ/ydFwWZaTOMAKHvI0=
-----END CERTIFICATE-----


$ openssl verify -CAfile servercrt1.pem cert.pem
cert.pem: OK


hat vielleicht jemand eine Idee?

 

[GNUisNotUnix]

hat wirklich keiner eine Idee, woran es liegen könnte?
vielliecht hat jemand schon Freetz + davfs2 + alice smartdisk eingerichtet, und könnte mir sagen mit welcher version es funktioniert?

freue mich über jede Hilfe

 

[olistudent]

Ohne dass ich dir jetzt weiterhelfen könnte liest sich das für mich so als würde was mit den Zertifikaten nicht stimmen.
http://freetz.org/wiki/packages/davfs2

Gruß
Oliver

 

[GNUisNotUnix]

Ja, anscheinend wird das Root-Zertifikat nicht richtig erkannt und das Zwischenzertifikat kann nicht verifiziert werden. Das Problem is,dass die Zeritifakte, laut openssl, die richtigen sind. Ich habe heute alles wieder in Linux gemacht, weil ich dachte, dass es ein Problem mit den CR/LF's geben könnte, aber ich bekomme immernoch dieselbe Fehlermeldung. Es scheint auch keine Möglichkeit zu geben, die Verifizierung der Zertifikate auszuschalten... Wenn ich das manuell mit mount -t davfs mounte, bekomme ich auch eine Meldung wegen der Zertifikate.

root@fritz:/var/tmp# cat /var/tmp/davfs2_1.conf 
secrets /var/davfs2/secrets_1
servercert /var/tmp/flash/davfs2/servercrt1.pem
root@fritz:/var/tmp# mount -t davfs https://dav.disk.alice.de alice -o conf=/var
/tmp/davfs2_1.conf
the server certificate is not trusted
  issuer:      Thawte, Inc., US
  subject:     IAU, HanseNet Telekommunikation GmbH, Hamburg, Hamburg, DE
  identity:    *.disk.alice.de
  fingerprint: d0:d4:18:16:16:b2:54:cb:45:42:9a:86:ba:38:6e:e2:cc:ea:ba:34
You only should accept this certificate, if you can
verify the fingerprint! The server might be faked
or there might be a man-in-the-middle-attack.
Accept certificate for this session? [y,N] y
warning: the server does not support locks
root@fritz:/var/tmp# mount
rootfs on / type rootfs (rw)
/dev/root on / type squashfs (ro)
dev on /dev type tmpfs (rw,nosuid)
devpts on /dev/pts type devpts (rw)
proc on /proc type proc (rw,nosuid,nodev,noexec)
tmpfs on /var type tmpfs (rw)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec)
/dev/mtdblock5 on /data type jffs2 (rw)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/sda1 on /var/media/ftp/uStor01 type ext2 (rw,noatime,nodiratime)
https://dav.disk.alice.de on /var/tmp/alice type fuse (rw,nosuid,nodev,user_id=0,group_id=0,allow_other,max_read=16384)

 

[olistudent]

Hast du es mal hiermit probiert? So wie es in der Anleitung steht? Und diese locks Option im Webinterface richtig gesetzt.

Gruß
Oliver

 

[GNUisNotUnix]

Mit diesem Zertifikat hat es funktioniert :-S .. aber ich verstehe wirklich nicht warum. Die Anleitung ist für GMX, und das Zertifikat von Alice braucht eigentlich ein Root und ein Zwischenzertifikat

$ openssl s_client -host dav.disk.alice.de -port 443
CONNECTED(00000003)
depth=2 /C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thaw
te, Inc. - For authorized use only/CN=thawte Primary Root CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/C=DE/ST=Hamburg/L=Hamburg/O=HanseNet Telekommunikation GmbH/OU=IAU/CN=*.di
sk.alice.de
   i:/C=US/O=Thawte, Inc./CN=Thawte SSL CA
 1 s:/C=US/O=Thawte, Inc./CN=Thawte SSL CA
   i:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte,
 Inc. - For authorized use only/CN=thawte Primary Root CA
 2 s:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte,
 Inc. - For authorized use only/CN=thawte Primary Root CA
   i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification S
ervices Division/CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.
com
---

Vielen Dank für deine Hilfe.. Aber wenn du auch eine Erklärung hast, warum das funktioniert hat, wäre super

 

[olistudent]

Für gmx braucht man ja auch nur das Thawte und nicht das von GMX. Liegt wahrscheinlich daran wie das mit der Certificate chain funktioniert...

Gruß
Oliver

 

[GNUisNotUnix]

komisch ist dass ich nur das Root-Zertifikat in der pem Datei habe und es funktioniert, obwohl das Zertifikat von ALice ein Zwischenzertifikat in der Chain hat... naja.. hauptsache es funktioniert

 

[RalfFriedl]

Der Client braucht immer nur die Root-Zertifikate. Der Server muss die Zwischen-Zertifikate schicken.

 

[otherland]

Ich habe genau dasselbe Problem, mit genau derselben Lösung, die ich noch nicht verstehe:

- Ich habe ein Login bei GMX, und möchte das MediaCenter einbinden
- Ich rufe wie in der Anleitung beschrieben https://webdav.mc.gmx.net auf
- Ich lasse mir das Zertifikat anzeigen

Dort finde ich eine Hierarchie von folgenden Zertifikaten:
1) thawte Primary Root CA
2) Thawte SSL CA
3) webdav.mc.gmx.net

Egal ob ich nur 1) oder nur 2) oder 1) und 2) hintereinander als Zertifikat in freetz ablege geht es *nicht*, mit der bekannten Fehlermeldung "Issuer not trusted".

Verwende ich aber das Zertifikat aus dem Posting von olistudent (thawte Premium Server CA), dann klappt das Einbinden ohne Fehlermeldung.

Was mich jetzt verwirrt:
- warum zeigt der Zugriff auf webdav.mc.gmx.net per Browser in der 'Page Info' ein anderes Zertifikat an (thawte Primary Root CA -> Thawte SSL CA)?
- warum führt das Zertifikat von olistudent (thawte Premium Server CA) zum erfolg, obwohl es scheinbar auf der Seite nicht verwendet wird?

 

[GNUisNotUnix]

Das Problem scheint zu sein, dass wenn man die Certificate-Chain mit einem Browser sieht, steht "thawte Primary Root CA" als Root-Cert (und Thawte SSL CA als Zwischenzertifikat), und "thawte Primary Root CA" ist da ein selbstsigniertes Zertifikat.

Openssl scheint die richtigen Infos zu zeigen:

Certificate chain
0 s:/C=DE/ST=Hamburg/L=Hamburg/O=HanseNet Telekommunikation GmbH/OU=IAU/CN=*.disk.alice.de
i:/C=US/O=Thawte, Inc./CN=Thawte SSL CA

1 s:/C=US/O=Thawte, Inc./CN=Thawte SSL CA
i:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA

2 s:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/[email protected]

Da steht "thawte Primary Root CA" nicht als ein selbstsigniertes Zertifikat. "thawte Primary Root CA" wurde von "Thawte Premium Server" ausgestellt und deswegen muss dieses Zertifikat installiert werden.

Für GMX ist genau dasselbe:

$ openssl s_client -host webdav.mc.gmx.net -port 443
CONNECTED(00000003)
depth=2 /C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thaw
te, Inc. - For authorized use only/CN=thawte Primary Root CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=webdav.mc.gmx.net
   i:/C=US/O=Thawte, Inc./CN=Thawte SSL CA
 1 s:/C=US/O=Thawte, Inc./CN=Thawte SSL CA
   i:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
 2 s:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
   i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.
com

https://www.thawte.com/roots/ :

Thawte Premium Server CA
Description: This root CA is the root currently used for Thawte Web Server Certificates and Code Signing Certificates. It is intended to be the primary root used for these products until mid 2010 when Thawte transitions to using a 2048 bit root. . After that transition this root will be used as part of a cross certification to ensure legacy applications continue to trust Thawte certificates and must continue to be included in root stores by vendors. Vendors should not plan on removing support for this root until officially advised that the root is no longer needed to support certificates or CRL validation.

Vielleicht hat diese "Cross-Zertifizierung" was damit zu tun....