Davfs2 - Stack: Linux: Certificaat plots niet meer vertrouwt - Internet en hosting

zaterdag 12 maart 2016 11:03

Acties:

0 Henk 'm!

BIEM!

Topicstarter

Ik mount mijn space op stack op mijn linuxserver (Ubuntu) via webdav/davfs2. Vervolgens maak ik daar backups op via duplicity. Dat ging tot 3 dagen geleden perfect, maar sindsdien wordt het server certificaat niet meer vertrouwt tijdens mounten:

code:

username@MijnServer:/etc/davfs2$ mount ~/mnt/stack/
/sbin/mount.davfs: the server certificate is not trusted
  issuer:      COMODO CA Limited, Salford, Greater Manchester, GB
  subject:     PositiveSSL Wildcard, Domain Control Validated
  identity:    *.stackstorage.com
  fingerprint: ae:5b:3b:fa:16:9a:f4:a1:79:c1:59:f8:7c:65:0d:fd:67:44:74:f6
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]

Ik kom er niet uit waaraan dit ligt. Ik kan het alleen voor 1 sessie vertrouwen, maar dat werkt dus niet bij automatische backups... daar ben ik niet altijd bij. Via de webbrowser kan ik zien dat ze gewoon een geldig certificaat hebben dat begonnen is is op 10 maart 2016 (dus wel nieuw!). Je kan dat zien door naar https://username.stackstorage.com te gaan en dan het certificaat te checken. Firefox, Chrome en IE vertrouwen dat ook gewoon.

Mijn fstab:

code:

1	https://username.stackstorage.com/remote.php/webdav/ /home/username/mnt/stack davfs user,rw,noauto 0 0

Mijn secrets file van davfs2 (zo heeft het altijd gewerkt)

code:

1	https://username.stackstorage.com/remote.php/webdav/ username MijnM031lijkeW4chtWo0rd

Servercert in davfs2.conf staat een # voor, die heb ik nooit ingevuld gehad.
Hoe krijg ik dit weer werkend? Moet ik ergens een certificaat installeren en waarom dan opeens en eerder niet?

zaterdag 12 maart 2016 12:40

Acties:

0 Henk 'm!

DJSmiley

Dat FF, chrome en IE je certificaat vertrouwen is 1, maar doet je ubuntu ding dat ook?

Ik heb zelf niet veel ervaring met Ubuntu en certificaten enz, maar mogelijk moet je de root/intermediatecertificaten van comodo updaten/installeren op je ubuntu bak zodat dat ding als trusted beschouwd en dus niet meer vraagt.

Of handmatig dat nieuwe certificaat lokaal installeren..

Ik zie ook (oudere) topics van mensen met een vergelijkbaar issue:
https://bugs.launchpad.ne...certificates/+bug/1261855

[ Voor 16% gewijzigd door DJSmiley op 12-03-2016 12:44 ]

zaterdag 12 maart 2016 12:45

Acties:

+1 Henk 'm!

Thralas

Jack Flushell schreef op zaterdag 12 maart 2016 @ 11:03:
Servercert in davfs2.conf staat een # voor, die heb ik nooit ingevuld gehad.
Hoe krijg ik dit weer werkend?

Nou, de pragmatische oplossin: vul hem eens in dan. Die optie heet overigens eigenlijk trust_ca_cert volgens mijn davfs2.conf man page, maar YMMV afhankelijk van je davfs2-versie.

Moet ik ergens een certificaat installeren en waarom dan opeens en eerder niet?

Zie het verhaal hierboven. Je browers hebben een eigen trust store, de sytemwide store van OpenSSL vind je in /etc/ssl.

Om te testen of je system trust store nog sane is kun je even proberen te connecten met OpenSSL's utilities:

openssl s_client -connect username.stackstorage.com:443

Als het hier broken blijkt heeft het updaten van de system trust store de voorkeur boven het handmatig voeren van een CA aan davfs2.

[ Voor 7% gewijzigd door Thralas op 12-03-2016 12:48 ]

zaterdag 12 maart 2016 13:07

Acties:

0 Henk 'm!

Jack Flushell

BIEM!

Topicstarter

Thralas schreef op zaterdag 12 maart 2016 @ 12:45:
openssl s_client -connect username.stackstorage.com:443
Als het hier broken blijkt heeft het updaten van de system trust store de voorkeur boven het handmatig voeren van een CA aan davfs2.

Dit geeft:

code:

CONNECTED(00000003)
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.stackstorage.com
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
 1 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
 3 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFXTCCBEWgAwIBAgIQPB1H7hi8hXaFOM/wEOQqZjANBgkqhkiG9w0BAQsFADCB
kDELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxNjA0BgNV
BAMTLUNPTU9ETyBSU0EgRG9tYWluIFZhbGlkYXRpb24gU2VjdXJlIFNlcnZlciBD
QTAeFw0xNjAzMTAwMDAwMDBaFw0xNjEwMjcyMzU5NTlaMF8xITAfBgNVBAsTGERv
bWFpbiBDb250cm9sIFZhbGlkYXRlZDEdMBsGA1UECxMUUG9zaXRpdmVTU0wgV2ls
ZGNhcmQxGzAZBgNVBAMMEiouc3RhY2tzdG9yYWdlLmNvbTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAN7C11xqQ1PJMvYBYToZOWZoPkvp1coSxMJerZZA
9fXh4n3ycAinTosKpmMTSial3cdXrgo0QkcaVj9JrvXdUAQzScaaEmJmEp85ybzD
+7Glx2f6OEpQfzu8rmQNZb3Tvb8nX0MIWdDmaPAgBJu1J7KBQ0dGUiC2uDWI01Hc
4MdNoW4HYTm+hsfjrPrRx7SwLCESlcY7QFkbumktDWCfk+Im2s3H54U8z2Bh9hPR
Vpespqk1SRR6wFniVuKcvE6U5/7lO3chBypWkStQZI3XKsNh7/YDpWSOwfDjJgw4
O5dG3eDX72/zrs65NSMiPfeWWXRUvDcYL6xWaj+awIWLGzcCAwEAAaOCAeEwggHd
MB8GA1UdIwQYMBaAFJCvajqUWgvYkOoSVnPfQ7Q6KNrnMB0GA1UdDgQWBBQ8FZbY
9QA/AKR22PZzXpu92bBbNjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd
BgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwTwYDVR0gBEgwRjA6BgsrBgEE
AbIxAQICBzArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8uY29t
L0NQUzAIBgZngQwBAgEwVAYDVR0fBE0wSzBJoEegRYZDaHR0cDovL2NybC5jb21v
ZG9jYS5jb20vQ09NT0RPUlNBRG9tYWluVmFsaWRhdGlvblNlY3VyZVNlcnZlckNB
LmNybDCBhQYIKwYBBQUHAQEEeTB3ME8GCCsGAQUFBzAChkNodHRwOi8vY3J0LmNv
bW9kb2NhLmNvbS9DT01PRE9SU0FEb21haW5WYWxpZGF0aW9uU2VjdXJlU2VydmVy
Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wLwYD
VR0RBCgwJoISKi5zdGFja3N0b3JhZ2UuY29tghBzdGFja3N0b3JhZ2UuY29tMA0G
CSqGSIb3DQEBCwUAA4IBAQAPbNwTMQ14ODg6biV9uo1g4NE8nzhNq6wksWx6y5nA
Hawz0LeeXKDvh3RvKO9GgByvgBLq728obxA0lKao3/fMBx0l+6WSpcFSLwiuABTl
F0DZwrj63LFx+fN+JnUfdyiPclvA7am+a/hhCRbwfq3WEPOrrP3RUICsaEXiVHh7
SqEaTTtzn6wJQtV3BQDTkUgWhuNHkW8kQpiZH72SF4yMxhpFQf9NaysWrw/tOJq+
wQ02vlnlUFSG5hMMgvJ6iACdItBLyr1ppWW/1NVZxqeGJNtYyiKBKU0uXM17qxU5
9KbqwYRnm8HtBHH440x3xW2mkzvpk/oZeb68CoVYzwqM
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.stackstorage.com
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
---
No client certificate CA names sent
---
SSL handshake has read 6075 bytes and written 421 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: 38905D653E90E1DF6E756AD45E138B54CA2DDF7E12E5DBE7AC9EFD3A92401C66
    Session-ID-ctx:
    Master-Key: 62E2F701BF011EE573497EDEAF8E372E66CA873E2C743D38709754D0A507B5DEDD50E343D77702FAE88BC962D8FCCB83
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 01 5f 5f b4 ff 98 4d 56-85 8a e2 76 f9 26 b6 3c   .__...MV...v.&.<
    0010 - e7 f9 7f 84 36 36 cd 98-74 bb 21 d6 d5 90 f8 68   ....66..t.!....h
    0020 - cb b0 01 08 29 26 f1 5d-97 cb 23 97 82 ad 63 ee   ....)&.]..#...c.
    0030 - 33 cb 0e de 64 1e f5 0c-cf e9 fa 08 01 4b e5 31   3...d........K.1
    0040 - 4d 26 5a bd cb 43 da 00-b9 6c 91 9e 97 e0 5a b5   M&Z..C...l....Z.
    0050 - c7 3d ec 38 e1 d1 fa b0-bc c0 cc 76 29 f3 fc 8c   .=.8.......v)...
    0060 - 44 ae f1 43 21 44 ea 07-70 85 a1 f2 80 fc 1d 5f   D..C!D..p......_
    0070 - 2c d7 5c 4c ea 2f 71 7e-a2 58 d8 82 dc cd b3 c3   ,.\L./q~.X......
    0080 - 93 3b 9e 4b a2 fa 06 53-0a 23 fd 39 ab aa 4e 21   .;.K...S.#.9..N!
    0090 - 26 8b 74 ab f0 73 95 b3-33 26 90 dc 41 2f 8b bf   &.t..s..3&..A/..

    Start Time: 1457784219
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---

Dit lijkt me dus in orde... Dan moet ik dus (opeens) een server certificate toevoegen. Kan ik dan gewoon de certificate-code dier hierboven staat in een file in /etc/davfs2/certs zetten en ernaar verwijzen in davfs2.conf? Ik vraag me wel echt af waarom dat nou opeens moet dan...

zaterdag 12 maart 2016 13:20

Acties:

0 Henk 'm!

Jack Flushell

BIEM!

Topicstarter

Dan moet ik dus (opeens) een server certificate toevoegen. Kan ik dan gewoon de certificate-code die hierboven staat in een file in /etc/davfs2/certs zetten en ernaar verwijzen in davfs2.conf? Ik vraag me wel echt af waarom dat nou opeens moet dan...

Dat werkt dus.

Kennelijk is de certificaat-database van Ubuntu niet (meer) up-to-date?
Dank voor de hulp.

zaterdag 12 maart 2016 13:35

Acties:

+1 Henk 'm!

ANdrode

code:

Get:1 Changelog for ca-certificates (http://changelogs.ubuntu.com/changelogs/pool/main/c/ca-certificates/ca-certificates_20160104ubuntu0.14.04.1/changelog) [34.3 kB]
ca-certificates (20160104ubuntu0.14.04.1) trusty-security; urgency=medium

  * Update ca-certificates database to 20160104:
    - backport changes from the Ubuntu 16.04 LTS 20160104 package

 -- Marc Deslauriers <marc.deslauriers@ubuntu.com>  Mon, 08 Feb 2016 10:28:49 -0500

Misschien door deze update (op mijn machines geupdate op 28-2)?

[ Voor 7% gewijzigd door ANdrode op 12-03-2016 13:36 ]

zaterdag 12 maart 2016 13:40

Acties:

0 Henk 'm!

Thralas

Jack Flushell schreef op zaterdag 12 maart 2016 @ 13:07:

code:

CONNECTED(00000003)
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify error:num=19:self signed certificate in certificate chain
verify return:0

Dit lijkt me dus in orde...

Niet echt, zie de error.

Je zou de root in /etc/ssl/certs/AddTrust_External_Root.pem moeten hebben (symlink naar /usr/share/ca-certificates/mozilla/AddTrust_External_Root.crt).

zaterdag 12 maart 2016 13:54

Acties:

0 Henk 'm!

Jack Flushell

BIEM!

Topicstarter

ANdrode schreef op zaterdag 12 maart 2016 @ 13:35:

code:

Get:1 Changelog for ca-certificates (http://changelogs.ubuntu.com/changelogs/pool/main/c/ca-certificates/ca-certificates_20160104ubuntu0.14.04.1/changelog) [34.3 kB]
ca-certificates (20160104ubuntu0.14.04.1) trusty-security; urgency=medium

  * Update ca-certificates database to 20160104:
    - backport changes from the Ubuntu 16.04 LTS 20160104 package

 -- Marc Deslauriers <marc.deslauriers@ubuntu.com>  Mon, 08 Feb 2016 10:28:49 -0500

Misschien door deze update (op mijn machines geupdate op 28-2)?

Blijkt het niet te zijn. Zie: http://gathering.tweakers.net/forum/view_message/46154527

[ Voor 5% gewijzigd door Jack Flushell op 12-03-2016 16:17 ]

zaterdag 12 maart 2016 13:56

Acties:

0 Henk 'm!

Jack Flushell

BIEM!

Topicstarter

Thralas schreef op zaterdag 12 maart 2016 @ 13:40:
[...]

Niet echt, zie de error.

Je zou de root in /etc/ssl/certs/AddTrust_External_Root.pem moeten hebben (symlink naar /usr/share/ca-certificates/mozilla/AddTrust_External_Root.crt).

Oh ik kijk scheel inderdaad. Dank.
Die file + symlink heb ik gewoon.

zaterdag 12 maart 2016 14:35

Acties:

+1 Henk 'm!

ANdrode

In de chain die opgestuurd wordt zit volgens Qualys een certificaat dat in de verkeerde volgorde in de chain zit.

Op een 14.04 machine accepteert hij de chain niet, terwijl het certificaat wel in de trust store staat. Op andere machines (o.a. Jessie en 15.10) accepteert hij de chain wel.

Het is het makkelijkst als TransIP dit voor iedereen oplost. Kan jij contact opnemen met de support?

zaterdag 12 maart 2016 16:02

Acties:

0 Henk 'm!

Jack Flushell

BIEM!

Topicstarter

ANdrode schreef op zaterdag 12 maart 2016 @ 14:35:
In de chain die opgestuurd wordt zit volgens Qualys een certificaat dat in de verkeerde volgorde in de chain zit.

Op een 14.04 machine accepteert hij de chain niet, terwijl het certificaat wel in de trust store staat. Op andere machines (o.a. Jessie en 15.10) accepteert hij de chain wel.

Het is het makkelijkst als TransIP dit voor iedereen oplost. Kan jij contact opnemen met de support?

Handige site, heel verhelderend! Dank!
Ik ga het aankaarten bij support!

Edit: Support is aangeschreven. Ik zal een update plaatsen als ik reactie heb.

[ Voor 5% gewijzigd door Jack Flushell op 12-03-2016 16:13 ]

zondag 13 maart 2016 09:22

Acties:

0 Henk 'm!

idef1x

Loop er net ook tegenaan en een search op google komt op o.a. tweakers uit $_/-\o_$

Hoe dan ook @ANdrode: op xubuntu 15.10 werkt het ook niet

zondag 13 maart 2016 12:23

Acties:

0 Henk 'm!

ANdrode

idef1x schreef op zondag 13 maart 2016 @ 09:22:
Hoe dan ook @ANdrode: op xubuntu 15.10 werkt het ook niet

Bij mijn machine (ubuntu 15.10) werkt het wel. Wat zie jij?
Ik heb echt getest met de hostname demo.stackstorage.com, maar met mijn eigen hostname krijg ik hetzelfde resultaat. Op applicatie niveau (dav2fs) werkt het ook.

code:

user@host:~$ openssl s_client -connect demo.stackstorage.com:443 -showcerts -tlsextdebug
CONNECTED(00000003)
TLS server extension "renegotiation info" (id=65281), len=1
&#8230;
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
verify return:1
depth=0 OU = Domain Control Validated, OU = PositiveSSL Wildcard, CN = *.stackstorage.com
verify return:1
...
Server certificate
subject=/OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.stackstorage.com
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
...
    Verify return code: 0 (ok)

Heeft één van jullie de trust_ca_cert optie van dav2fs geprobeerd?

zondag 13 maart 2016 12:29

Acties:

0 Henk 'm!

redfoxert

Afgelopen donderdag kreeg ik ook mails dat mijn STACK offline was. Wellicht heeft een en ander er mee te maken?

https://discord.com/invite/tweakers

zondag 13 maart 2016 13:03

Acties:

0 Henk 'm!

RobinF

redfoxert schreef op zondag 13 maart 2016 @ 12:29:
Afgelopen donderdag kreeg ik ook mails dat mijn STACK offline was. Wellicht heeft een en ander er mee te maken?

Jep, hier hetzelfde. Blijkbaar is m'n STACK daardoor verplaatst ofzo. Overigens wel netjes dat ze dat emailen naar je

zondag 13 maart 2016 14:34

Acties:

0 Henk 'm!

idef1x

ANdrode schreef op zondag 13 maart 2016 @ 12:23:
[...]

Bij mijn machine (ubuntu 15.10) werkt het wel. Wat zie jij?

Oef

Sukkel die ik ben...mijn werkstation is xubuntu 15.10 (werkt inderdaad), maar de machine die mijn backup naar stack zet draait op 14.04 ..zat met wat teveel terminal schermpjes open denk ik

Ik heb niets gezegd

zondag 13 maart 2016 14:38

Acties:

0 Henk 'm!

ANdrode

idef1x schreef op zondag 13 maart 2016 @ 14:34:
[...]
Sukkel die ik ben...mijn werkstation is xubuntu 15.10 (werkt inderdaad), maar de machine die mijn backup naar stack zet draait op 14.04 ..zat met wat teveel terminal schermpjes open denk ik
Ik heb niets gezegd

Been there. Ik maak zo'n vergissing liever met zoiets dan met een shutdown

.

Kan jij de trust_ca_cert optie van dav2fs proberen? Ik verwacht dat het daarmee wel werkt.

zondag 13 maart 2016 14:53

Acties:

0 Henk 'm!

idef1x

Denk dat ik het niet helemaal begrijp wat ze nu precies willen in die link van je.
In mijn ~/.davfs2/certs heb ik het certificaat gesymlinked naar de mozillastore en in de ~/.davfs2/davfs.conf de setting:

trust_ca_cert

toegevoegd...moet ik hier nog het pad achter geven naar het cert? Zou onlogisch zijn ,want waarom dan in de certs directry zetten...
Afijn werkt nog niet in ieder geval

maandag 14 maart 2016 14:59

Acties:

0 Henk 'm!

Jack Flushell

BIEM!

Topicstarter

Tijdelijke oplossing (voor wie het er nog niet uitgehaald had):

Zet onderstaande (public key) in een filetje /etc/davfs2/certs/stack.pem

code:

Zet in /etc/davfs2/davfs2.conf:

code:

1	serververcert /etc/davfs2/certs/stack.pem

Vergeet niet de # weg te halen natuurlijk.

Ik heb nog geen reactie gehad van TransIP.

[ Voor 3% gewijzigd door Jack Flushell op 14-03-2016 15:02 ]

maandag 14 maart 2016 16:43

Acties:

0 Henk 'm!

thepizzX

het is intussen gefixed.

was inderdaad de verkeerde volgorde van certificaten.

maandag 14 maart 2016 19:31

Acties:

0 Henk 'm!

Jack Flushell

BIEM!

Topicstarter

thepizzX schreef op maandag 14 maart 2016 @ 16:43:
het is intussen gefixed.

was inderdaad de verkeerde volgorde van certificaten.

Ah vast iemand van TransIP, had link naar dit topic bij mijn ticket geplakt

.
Inderdaad. Ik kreeg net deze e-mail:

Beste ,

Met dit bericht willen wij je op de hoogte stellen van een ticket.
Je kunt dit ticket lezen door naar je controlepaneel te gaan, of door op de volgende link te klikken:

https://www.transip.nl/ticket

Onder dit bericht vind je voor het gemak de inhoud van het ticket.

Wij raden je echter aan je reactie via ons online ticketsysteem in te dienen, in plaats van een reply op deze e-mail.

Met vriendelijke groet,

TransIP
Tevreden of ontevreden over ons antwoord? Geef je mening via onze website.

Ik heb het getest en het werkt inderdaad weer 'out-of-the-box'.

[ Voor 22% gewijzigd door Jack Flushell op 14-03-2016 19:41 . Reden: typo ]

dinsdag 15 maart 2016 09:34

Acties:

0 Henk 'm!

idef1x

Yep werkt inderdaad weer gewoon

dinsdag 15 maart 2016 12:38

Acties:

0 Henk 'm!

thepizzX

Nee hoor,

Gewoon user met zelfde issue en ook een ticket.

Ze pakken dit wel voortvarend op bij Transip.

Pagina: 1

Reageer