donders-research-data-management / rdm-wiki

Technical documentation for RDM
http://donders-research-data-management.github.io/rdm-wiki
1 stars 2 forks source link

Problem with TLS certificate of webdav.data.donders.ru.nl #29

Closed JoKeyser closed 8 years ago

JoKeyser commented 8 years ago

Hi, I hope this isn't the worst place to post this issue... I've followed the guide how to connect to webdav.data.donders.ru.nl with Thunar, version 1.6.10.

When I try to connect, I get an error message:

The site's identity can't be verified:
    The signing certificate authority is not known.

    The signing certificate authority is not known.

Certificate information:
    Identity: webdav.data.donders.ru.nl
    Verified by: TERENA SSL CA 3
    Expires: 02/27/2019
    Fingerprint (SHA1): 67 1B E0 87 C8 BE 75 89 7B 3D 00 23 05 67 26 9A 2C 79 87 29

Are you really sure you would like to continue?

If I click Yes, it still doesn't work and simply responds:

Failed to open "File System".
HTTP Error: Unacceptable TLS certificate.
JoKeyser commented 8 years ago

If I request the certificate via the openssl client (using openssl s_client -connect webdav.data.donders.ru.nl:443), it confirms that it's not just Thunar who has an issue with the certificate. It seems a problem with verifying the certificate.

Here's the full dump, in case it helps:

> openssl s_client -connect webdav.data.donders.ru.nl:443
CONNECTED(00000003)
depth=0 C = NL, ST = Gelderland, L = Nijmegen, O = Radboud Universiteit Nijmegen, CN = webdav.data.donders.ru.nl
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = NL, ST = Gelderland, L = Nijmegen, O = Radboud Universiteit Nijmegen, CN = webdav.data.donders.ru.nl
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/C=NL/ST=Gelderland/L=Nijmegen/O=Radboud Universiteit Nijmegen/CN=webdav.data.donders.ru.nl
   i:/C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA SSL CA 3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFRDCCBCygAwIBAgIQB2p+hPhDqUsN2yWpDcgyPjANBgkqhkiG9w0BAQsFADBk
MQswCQYDVQQGEwJOTDEWMBQGA1UECBMNTm9vcmQtSG9sbGFuZDESMBAGA1UEBxMJ
QW1zdGVyZGFtMQ8wDQYDVQQKEwZURVJFTkExGDAWBgNVBAMTD1RFUkVOQSBTU0wg
Q0EgMzAeFw0xNjAyMjMwMDAwMDBaFw0xOTAyMjcxMjAwMDBaMIGBMQswCQYDVQQG
EwJOTDETMBEGA1UECBMKR2VsZGVybGFuZDERMA8GA1UEBxMITmlqbWVnZW4xJjAk
BgNVBAoTHVJhZGJvdWQgVW5pdmVyc2l0ZWl0IE5pam1lZ2VuMSIwIAYDVQQDExl3
ZWJkYXYuZGF0YS5kb25kZXJzLnJ1Lm5sMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAxLkunRU2hWLGPrkJIfXLSiZVYQBOezBMHEpbWFWnSpDcdDW3lL+a
q1rhN5/KXDow/GfALjIIax9Kic6AVAbvtEJR8dTzKFcDZNYztbVoCovhCYcJxRf2
XeNmPbNiblL/wdhrOdxh/mZC0wTQhIKQp4KKOG5bHV4AV5VMoolV7iQtiIdr/C0V
lUBTMtbvUSh0ZzerhS9EzdHOeS0pUNbPiWxuceTjor+CfT64RDvtemxFwrg/aSco
qKC5ogU1znFEmoIi/KDku3fqZ44NA00NWKLfRNVOAZGn5XFvsKvEkJJXhvs7xmLe
pVswIvROBlwLoGGSdSQ98H2HSpCtTpPUrQIDAQABo4IB0jCCAc4wHwYDVR0jBBgw
FoAUZ/2IIBQnmMcJ0iUZu+lREWN1UGIwHQYDVR0OBBYEFKpn25QldFblzp3JcBep
NZbLoOMMMCQGA1UdEQQdMBuCGXdlYmRhdi5kYXRhLmRvbmRlcnMucnUubmwwDgYD
VR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBrBgNV
HR8EZDBiMC+gLaArhilodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVEVSRU5BU1NM
Q0EzLmNybDAvoC2gK4YpaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL1RFUkVOQVNT
TENBMy5jcmwwTAYDVR0gBEUwQzA3BglghkgBhv1sAQEwKjAoBggrBgEFBQcCARYc
aHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAIBgZngQwBAgIwbgYIKwYBBQUH
AQEEYjBgMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wOAYI
KwYBBQUHMAKGLGh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9URVJFTkFTU0xD
QTMuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQELBQADggEBABw7Q7FZDkMB
mYWi4ncFJd7KXvr2gvk73lEPHGFoBD/ASHjKumHj3jbgBZY1gLi4kFOd9eR3oztK
DQyom4ifvgYVOdlev4W2eYJpJATtml3raa4lR3SWZNbpZokZoET2GbTIxxNG9x11
eeove4l8jdd8w/z9zbsGg8oEq1/2LHgwMNNTS8BqGuekH3AT1iBa3SOZC5ZhS1TR
VzM1+EjBPSCrx+pHCM3MLqvdmyvJxnuN3W7NohKmlgAimwolssRHuIPxAguXa8N+
1fxKXX6Uy/bFWIRxwhXE48pHKvT3/EZhgaqRmTO48IJd+gSH3H+u665bdFTnoD3B
US9fInQsKK4=
-----END CERTIFICATE-----
subject=/C=NL/ST=Gelderland/L=Nijmegen/O=Radboud Universiteit Nijmegen/CN=webdav.data.donders.ru.nl
issuer=/C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA SSL CA 3
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2043 bytes and written 433 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 524A44A97BCD12234980F7374011948C48FB4EBFD1F3959852A22373E52C9B28
    Session-ID-ctx: 
    Master-Key: 80DA858D032C39E548FBECA73F5EDD93E632A78AA9F97665367020423D8DB2FA502B1B14DBA9ED669B33978F49574AB3
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 7f b2 cf 32 0a 50 2a ac-e8 6d 65 06 a7 e2 76 fd   ...2.P*..me...v.
    0010 - cc 4b 69 2c 11 36 d7 23-20 f5 a1 d8 ea 42 3e 74   .Ki,.6.# ....B>t
    0020 - 7c a5 69 5b 62 cc b9 15-bb c8 b6 61 4d ab 7c 5a   |.i[b......aM.|Z
    0030 - 77 9d 7e 42 78 b8 fd 10-cb 3a 3b 9b c3 41 aa 3e   w.~Bx....:;..A.>
    0040 - 18 3c 2e e1 0d b9 ad 3a-fb 98 7d c2 a7 e7 bb c9   .<.....:..}.....
    0050 - 53 3f 63 23 07 c4 d1 55-d8 2e 8a b3 29 23 5d a5   S?c#...U....)#].
    0060 - db 31 1b 96 4a f8 44 23-6d 44 5a 22 78 60 4d 3c   .1..J.D#mDZ"x`M<
    0070 - 95 31 09 74 ad 21 72 c4-ba a1 db eb 00 bd 9c 5f   .1.t.!r........_
    0080 - 37 52 be 7e b3 6f ea a8-92 75 41 39 e6 20 5f 6e   7R.~.o...uA9. _n
    0090 - b5 8f b4 42 73 8e d2 07-b5 11 51 28 0f 5b ad fc   ...Bs.....Q(.[..
    00a0 - 75 80 27 58 24 f9 1b 6a-a0 ba 69 5b e1 fa 1e ab   u.'X$..j..i[....
    00b0 - e0 fe 36 62 e4 2e e2 83-57 6c de a4 83 7d ce 89   ..6b....Wl...}..

    Start Time: 1461334263
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)
JoKeyser commented 8 years ago

Okay I've checked now also with cadaver, which also warns me about the untrusted certificate, but at least works if I'm accepting it anyways:

cadaver https://webdav.data.donders.ru.nl
WARNING: Untrusted server certificate presented for `webdav.data.donders.ru.nl':
Issued to: Radboud Universiteit Nijmegen, Nijmegen, Gelderland, NL
Issued by: TERENA, Amsterdam, Noord-Holland, NL
Certificate is valid from Tue, 23 Feb 2016 00:00:00 GMT to Wed, 27 Feb 2019 12:00:00 GMT
Do you wish to accept the certificate? (y/n) y
Authentication required for irods on server `webdav.data.donders.ru.nl':
Username: UXXXXXX-ru.nl
Password: XXXXXXX
dav:/> 
dav:/> ls
Listing collection `/': succeeded.
Coll:   dcc                                    0  Mar  2 17:47
Coll:   dccn                                   0  Mar  2 17:47
Coll:   dcn_m                                  0  Mar  2 17:47
Coll:   dcn_s                                  0  Mar  2 17:47
robertoostenveld commented 8 years ago

Hi Johannes, this is not a bad place to post this. @hurngchunlee will read it here, and he is the one who can help you with this (or forward the issue to our ISC colleagues).

JoKeyser commented 8 years ago

Hi Robert, thanks for clarifying. Now I've got aware that @hurngchunlee filed already a bug report about this to the CyberDuck developers. However, with all of these programs complaining, it seems more likely that something's weird about the certificate.

hurngchunlee commented 8 years ago

It's due to the fact that your computer ( or client application) does not trust the Certificate Authority (TERENA) by which the webdav server's certificate is issued.

To make your computer (client application) trust the TERENA CA, one needs to install the CA's certificate which can be downloaded from: https://www.terena.org/activities/tcs/repository-g3/TERENA_SSL_CA_3.pem

However, where to put this file in the computer depends on Linux distribution and application. I will figure it out and make a structural summary on the guide.

But it is interesting that your Thunar application still gives error even after you trust it "manually" (i.e. type 'yes' explicitly). On my Ubuntu desktop, the openssl command also gives some "error"; but if I just connect the webdav server with Thunar (version 1.6.3), it just connects. Do you specify the URL as: davs://webdav.data.donders.ru.nl?

JoKeyser commented 8 years ago

Hi, thanks for your fast reaction. Yes I was using exactly davs://webdav.data.donders.ru.nl. The missing trust in the "TERENA SSL CA 3" would explain the main issue. So far I've never had this problem with any server from RU, probably because they include one more signature from a more commonly trusted CA?
For example, data.donders.ru.nl also includes DigiCert as the last signature:

Certificate chain
 0 s:/C=NL/ST=Gelderland/L=Nijmegen/O=Radboud Universiteit Nijmegen/CN=klampkever.uci.ru.nl
   i:/C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA SSL CA 3
 1 s:/C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA SSL CA 3
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root C

Of course I can install this certificate manually, but I doubt that's a great solution for all future users. Playing the devil's advocate: If this needs manual intervention, you could as well not use any CA at all, and post the fingerprint on the website and ask people to just accept it manually...

I will install it though, and see whether Thunar's behaviour is a bug indeed (I agree, it looks like it).

hurngchunlee commented 8 years ago

Indeed, the more common certificate of DigiCert is not included. I will ask ISC colleague to check it.

hurngchunlee commented 8 years ago

ok. I suppose the trust issue of server certificate has been fixed, and there is no need to install TERENA CA on the client side.

It turns out to be a line in the config file of the Apache Httpd server being commented out; therefore the entire certificate chain (up to the DigiCert CA) is not presented to the client. The server certificate itself is fine. Nevertheless, the client should still trust the DigiCert CA, which is generally the case nowadays (in most of cases, it is installed as part of the OS).

Just check it again with the openssl command, and it's now a verified certificate:

$ openssl s_client -connect webdav.data.donders.ru.nl:443

depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Assured ID Root CA
verify return:1
depth=1 C = NL, ST = Noord-Holland, L = Amsterdam, O = TERENA, CN = TERENA SSL CA 3
verify return:1
depth=0 C = NL, ST = Gelderland, L = Nijmegen, O = Radboud Universiteit Nijmegen, CN = webdav.data.donders.ru.nl
verify return:1
---
Certificate chain
 0 s:/C=NL/ST=Gelderland/L=Nijmegen/O=Radboud Universiteit Nijmegen/CN=webdav.data.donders.ru.nl
   i:/C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA SSL CA 3
 1 s:/C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA SSL CA 3
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA
---
...
    Start Time: 1461354368
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

I also figured out that cadaver will need to be built with the option --with-ca-bundle to specify the location of the ROOT CA bundle. I fixed the installation in the DCCN cluster. I suppose the option should be included if the cadaver is installed from a package manager (YUM, RPM, APT) ... but not 100% sure.

I couldn't check if the issue with Thunar is also resolved as I was not able to reproduce it in the systems I have access. I hope the fix in the Apache config file also resolves it. Please let me know. Thanks!

JoKeyser commented 8 years ago

Okay great, it seems all fixed now (even before I got around to install the missing certificate, so we'll never know :)). I checked with Thunar and Cadaver, both are connecting now without any issue and exactly like in the documented. Thank you for resolving this so quickly!

PS: So probably it's now also fine with CyberDuck, which I haven't installed (Thunar seems sufficient to me). Let me know if you want me to check that, but I guess your tests are much more comprehensive (e.g. including Windows).

hurngchunlee commented 8 years ago

Thanks for the test. I think CyberDuck should be fine as I have tested it on Windows and Mac. For the moment, I will close the issue.