I’m new to this forum and I ran into a little problem yesterday when upgrading from Raspbmc on Raspberri Pi 1 to the latest OSMC version Linux osmc 3.18.13-1-osmc #1. In the previous version of Raspbmc, I have no problem accessing a WebDAV-share over HTTPS via the internet on my synology at home (portforwarding and firewall is all ok, checked it from separate computer). So I turned on the logging on the osmc Pi and saw several issues related to the certificate/security when the Pi connects to the Synology (relevant lines are bold and names/ip addresses have been changed):
20:51:06 T:3023634992 DEBUG: ------ Window Deinit (DialogBusy.xml) ------
20:51:08 T:3023634992 DEBUG: Keyboard: scancode: 0x1c, sym: 0x000d, unicode: 0x0000, modifier: 0x0
20:51:08 T:3023634992 DEBUG: OnKey: return (0xf00d) pressed, action is Select
20:51:08 T:2855007264 DEBUG: CurlFile::Open(0xaa2beba8) https://mysynology.example.com:5006/
20:51:08 T:2855007264 DEBUG: Curl::Debug - TEXT: Hostname was found in DNS cache
20:51:08 T:2855007264 DEBUG: Curl::Debug - TEXT: Trying 1.2.3.4…
20:51:08 T:2855007264 DEBUG: Curl::Debug - TEXT: Connected to mysynology.example.com (1.2.3.4) port 5006 (#1)
20:51:08 T:2855007264 DEBUG: Curl::Debug - TEXT: found 173 certificates in /etc/ssl/certs/ca-certificates.crt
20:51:08 T:2855007264 DEBUG: Curl::Debug - TEXT: SSL re-using session ID
20:51:08 T:2855007264 DEBUG: Curl::Debug - TEXT: gnutls_handshake() warning: The server name sent was not recognized
20:51:08 T:2855007264 DEBUG: Curl::Debug - TEXT: common name: WARNING couldn’t obtain
20:51:08 T:2855007264 DEBUG: Curl::Debug - TEXT: server certificate verification SKIPPED
20:51:08 T:2855007264 DEBUG: Curl::Debug - TEXT: error fetching CN from cert:The requested data were not available. 20:51:08 T:2855007264 DEBUG: Curl::Debug - TEXT: common name: (does not match ‘mysynology.example.com’) 20:51:08 T:2855007264 DEBUG: Curl::Debug - TEXT: server certificate expiration date verify FAILED 20:51:08 T:2855007264 DEBUG: Curl::Debug - TEXT: server certificate activation date verify FAILED
20:51:08 T:2855007264 DEBUG: Curl::Debug - TEXT: certificate public key: (nil)
20:51:08 T:2855007264 DEBUG: Curl::Debug - TEXT: certificate version: #1
20:51:08 T:2855007264 DEBUG: Curl::Debug - TEXT: subject:
20:51:08 T:2855007264 DEBUG: Curl::Debug - TEXT: start date: Wed, 31 Dec 1969 23:59:59 GMT
20:51:08 T:2855007264 DEBUG: Curl::Debug - TEXT: expire date: Wed, 31 Dec 1969 23:59:59 GMT
20:51:08 T:2855007264 DEBUG: Curl::Debug - TEXT: issuer:
20:51:08 T:2855007264 DEBUG: Curl::Debug - TEXT: compression: NULL
20:51:08 T:2855007264 DEBUG: Curl::Debug - TEXT: cipher: NULL
20:51:08 T:2855007264 DEBUG: Curl::Debug - TEXT: MAC: MAC-NULL
20:51:08 T:2855007264 DEBUG: Curl::Debug - TEXT: Server auth using Basic with user ‘example’
20:51:08 T:2855007264 DEBUG: Curl::Debug - HEADER_OUT: PROPFIND / HTTP/1.1
20:51:08 T:2855007264 DEBUG: Curl::Debug - HEADER_OUT: Authorization: Basic c3RvZmZlbHM6MTB3aR0ZXdpbmQh
20:51:08 T:2855007264 DEBUG: Curl::Debug - HEADER_OUT: Range: bytes=0-
20:51:08 T:2855007264 DEBUG: Curl::Debug - HEADER_OUT: User-Agent: OSMC/Open Source Media Center
20:51:08 T:2855007264 DEBUG: Curl::Debug - HEADER_OUT: Host: mysynology.example.com:5006
20:51:08 T:2855007264 DEBUG: Curl::Debug - HEADER_OUT: Accept: /
20:51:08 T:2855007264 DEBUG: Curl::Debug - HEADER_OUT: Accept-Charset: UTF-8,*;q=0.8
20:51:08 T:2855007264 DEBUG: Curl::Debug - HEADER_OUT: Content-Type: text/xml; charset=“utf-8”
20:51:08 T:2855007264 DEBUG: Curl::Debug - HEADER_OUT: depth: 1 20:51:08 T:2855007264 DEBUG: Curl::Debug - TEXT: GnuTLS recv error (-15): An unexpected TLS packet was received. 20:51:08 T:2855007264 DEBUG: Curl::Debug - TEXT: Closing connection 1 20:51:08 T:2855007264 ERROR: CCurlFile::FillBuffer - Failed: Failure when receiving data from the peer(56)
20:51:08 T:2855007264 ERROR: CCurlFile::CReadState::Connect, didn’t get any data from stream.
Has anyone ever encountered this error before and could it be solved without having to install a publicly signed SSL certificate onto my Synology?
It’s hard to know what to suggest when it looks like you’ve modified the log file - I’m assuming your nas’s hostname isn’t called mysynology.example.com
It’s not the fact that your certificate is self signed that is the issue, it’s complaining that the common name in the certificate does not match the hostname that you’re connecting by.
Possibly the reason you were not seeing this on Raspbmc is that there was a long standing bug in OpenSSL where certificates were not always being correctly verified - this was fixed a month or two ago and in the process it has tightened up the checking that is done on certificates.
With Raspbmc the core OS was never updated, with OSMC you are updating the underlying Debian OS when you run updates, thus bringing OpenSSL (and all other parts of the OS) current, so you will get these up to date OpenSSL fixes.
I would suggest that you seek out a firmware update for your NAS - there is obviously a problem with the self signed cert that it is generating or that the cert has expired. (not uncommon in appliances, if you don’t update them from time to time…)
Edit: just noticed that the expiry date for the cert is 1969 so the cert is definitely bogus. Update the firmware on the NAS or check the support forums for the NAS for a fix.
Thank you for replying to my post and helping out, much appreciated.
What you say is true, it is indeed complaining about the common name and the validity of the certificate has long expired, heck it didn’t even exist back in 1969 I totally understand that now the underlying openSSL and gnutls modules have been updated, things have become more stricter and are being checked more thoroughly.
Today I’ve gone to great lengths in trying to solve the problem, also following up on your advice, but alas. Here’s what I found/did:
The SSL certificate did check out in all the browsers that I used it with (it was self signed, but had another expiration date than 1969).
The firmware of the NAS was already up to date at the moment I first about posted the problem.
I had the self signed certificate (SHA-1) replaced with a newer self-signed certificate (SHA-256) which was visible in the browser, but unfortunately again not by OSMC.
Finally, I bought a COMODO public signed 4096-bit certificate and put it on the NAS. It checks out fine on all SSL-checks from Digicert and other parties I have used. It also shows up fine in both Firefox and Chrome (it really presents this new public CA signed certificate).
Again, I’ve changed the ip address and hostname, but the log is exactly the same as with the self signed certificate.
21:19:16 58.208248 T:2831803424 DEBUG: CurlFile::Open(0xa8c9db90) https://mysynology.example.com:5006/
21:19:16 58.210934 T:2831803424 INFO: easy_aquire - Created session to https://mysynology.example.com
21:19:16 58.217548 T:2831803424 DEBUG: Curl::Debug - TEXT: Hostname was NOT found in DNS cache
21:19:17 58.420845 T:2831803424 DEBUG: Curl::Debug - TEXT: Trying 81.148.62.117…
21:19:17 58.426182 T:2831803424 DEBUG: Curl::Debug - TEXT: Connected to mysynology.example.com (81.148.62.117) port 5006 (#0)
21:19:17 58.710716 T:3023901232 DEBUG: ------ Window Init (DialogBusy.xml) ------
21:19:17 59.063995 T:2843599904 DEBUG: OSMC ADDON MAIN Current Version: OSMC July 2015 2015.07-1
21:19:17 59.097061 T:2843599904 DEBUG: OSMC ADDON MAIN main addon starting
21:19:17 59.188286 T:2714100768 DEBUG: OSMC COMMS: Comms started
21:19:17 59.191071 T:2843599904 DEBUG: osmc_settings: settings.create_gui received: pos0: <OSMCGui(Thread-2, initial)>
21:19:17 59.263924 T:2843599904 DEBUG: osmc_settings: settings.retrieve_modules received: pos0: <OSMCGui(Thread-2, initial)>
21:19:18 59.372105 T:2831803424 DEBUG: Curl::Debug - TEXT: found 173 certificates in /etc/ssl/certs/ca-certificates.crt 21:19:18 59.740910 T:2831803424 DEBUG: Curl::Debug - TEXT: gnutls_handshake() warning: The server name sent was not recognized 21:19:18 59.741516 T:2831803424 DEBUG: Curl::Debug - TEXT: common name: WARNING couldn’t obtain 21:19:18 59.741814 T:2831803424 DEBUG: Curl::Debug - TEXT: server certificate verification SKIPPED
21:19:18 59.743050 T:2831803424 DEBUG: Curl::Debug - TEXT: error fetching CN from cert:The requested data were not available.
21:19:18 59.743950 T:2831803424 DEBUG: Curl::Debug - TEXT: common name: (does not match ‘mysynology.example.com’) 21:19:18 59.744293 T:2831803424 DEBUG: Curl::Debug - TEXT: server certificate expiration date verify FAILED 21:19:18 59.744705 T:2831803424 DEBUG: Curl::Debug - TEXT: server certificate activation date verify FAILED
21:19:18 59.745190 T:2831803424 DEBUG: Curl::Debug - TEXT: certificate public key: (nil)
21:19:18 59.754223 T:2831803424 DEBUG: Curl::Debug - TEXT: certificate version: #1
21:19:18 59.755878 T:2831803424 DEBUG: Curl::Debug - TEXT: subject:
21:19:18 59.756310 T:2831803424 DEBUG: Curl::Debug - TEXT: start date: Wed, 31 Dec 1969 23:59:59 GMT
21:19:18 59.756622 T:2831803424 DEBUG: Curl::Debug - TEXT: expire date: Wed, 31 Dec 1969 23:59:59 GMT
21:19:18 59.756901 T:2831803424 DEBUG: Curl::Debug - TEXT: issuer:
21:19:18 59.757385 T:2831803424 DEBUG: Curl::Debug - TEXT: compression: NULL
21:19:18 59.757668 T:2831803424 DEBUG: Curl::Debug - TEXT: cipher: NULL
21:19:18 59.758034 T:2831803424 DEBUG: Curl::Debug - TEXT: MAC: MAC-NULL
21:19:18 59.758465 T:2831803424 DEBUG: Curl::Debug - TEXT: Server auth using Basic with user ‘example’
21:19:18 59.759315 T:2831803424 DEBUG: Curl::Debug - HEADER_OUT: PROPFIND / HTTP/1.1
21:19:18 59.772942 T:2831803424 DEBUG: Curl::Debug - HEADER_OUT: Authorization: Basic c3RvZmZlbHM6MB3aXR0ZXdpbmQh
21:19:18 59.773308 T:2831803424 DEBUG: Curl::Debug - HEADER_OUT: Range: bytes=0-
21:19:18 59.773537 T:2831803424 DEBUG: Curl::Debug - HEADER_OUT: User-Agent: OSMC/Open Source Media Center
21:19:18 59.773720 T:2831803424 DEBUG: Curl::Debug - HEADER_OUT: Host: mysynology.example.com:5006
21:19:18 59.773895 T:2831803424 DEBUG: Curl::Debug - HEADER_OUT: Accept: /
21:19:18 59.774071 T:2831803424 DEBUG: Curl::Debug - HEADER_OUT: Accept-Charset: UTF-8,*;q=0.8
21:19:18 59.774246 T:2831803424 DEBUG: Curl::Debug - HEADER_OUT: Content-Type: text/xml; charset=“utf-8”
21:19:18 59.774422 T:2831803424 DEBUG: Curl::Debug - HEADER_OUT: depth: 1 21:19:18 59.775036 T:2831803424 DEBUG: Curl::Debug - TEXT: GnuTLS recv error (-15): An unexpected TLS packet was received.
21:19:18 59.775364 T:2831803424 DEBUG: Curl::Debug - TEXT: Closing connection 0
21:19:18 59.888996 T:2831803424 ERROR: CCurlFile::FillBuffer - Failed: Failure when receiving data from the peer(56)
21:19:18 59.889423 T:2831803424 ERROR: CCurlFile::Open failed with code 0 for davs://USERNAME:PASSWORD@mysynology.example.com:5006/
21:19:18 59.889687 T:2831803424 ERROR: GetDirectory - Unable to get dav directory (davs://USERNAME:PASSWORD@mysynology.example.com:5006/)
21:19:18 59.922112 T:3023901232 ERROR: GetDirectory - Error getting davs://USERNAME:PASSWORD@mysynology.example.com:5006/
21:19:18 59.922569 T:3023901232 ERROR: CGUIDialogFileBrowser::GetDirectory(davs://USERNAME:PASSWORD@mysynology.example.com:5006/) failed
I have also completely wiped the sd-card and reinstalled OSMC and updated to the July build, but still no go.
@DBMandrake: according to the SSL check of Digicert the URL of my NAS in port 5006 supports TLS 1.0, 1.1 and 1.2.
I’m pretty sure port 5006 is using TLS, because when I try to access it through http I get the following message:
Bad Request
Your browser sent a request that this server could not understand.
Reason: You’re speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.
The reason I’m using Webdav over HTTPS, is because I’m streaming most of the data over the internet to the Pi and I’d like this to be as secure as possible. In my local environment everything goes through SMB/CIFS shares of course.
@sam_nazarko: you were right, the first two commands did fail.
osmc@osmc:~$ openssl s_client -showcerts -connect mysynology.example.com:5006
CONNECTED(00000003)
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
verify error:num=20:unable to get local issuer certificate
verify return:0
Server certificate
subject=/OU=Domain Control Validated/OU=PositiveSSL/CN=mysynology.example.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 4108 bytes and written 421 bytes
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: 86E6D1B2006B060C5D83FDEAE3DCFFCFB3D66150D33CB98C75F72D4389C064E6
Session-ID-ctx:
Master-Key: F800970F126CB1639F61D8CD7F691C3FFFC20A02430E400D68282F4D849F5E923F1537EB3426C7E2B7D13FFD5C22C3A2
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 9a 2e a5 b7 b8 e5 b3 d4-d2 57 45 a3 00 fc 3f 80 …WE…?.
0010 - cd 8a 0e ae 29 94 f5 5e-05 1c 26 d8 12 02 55 6f …)…^…&…Uo
0020 - 8a 8f 2b 4e 8f 02 3a 94-65 bb e7 7a 35 7c 0e ea …+N…:.e…z5|…
0030 - e4 a2 10 1e d7 ac f0 04-3e a0 9d ba 47 2b 94 30 …>…G+.0
0040 - 74 d2 2b 88 93 c1 87 58-f1 39 1f 6b af 3a 14 ac t.+…X.9.k.:…
0050 - cc 5a 8c e8 3a ea 73 76-d6 5a 12 06 ea 3b 62 fc .Z…:.sv.Z…;b.
0060 - 3d 90 70 09 6e ba 3c 74-f8 5d c3 93 63 bf 63 24 =.p.n.<t.]…c.c$
0070 - 3e d8 d2 e8 4c 69 31 92-5d 3a bd 56 6c ae f5 37 >…Li1.]:.Vl…7
0080 - 17 66 38 e6 89 90 8d ce-c2 47 c4 86 ef 56 61 e2 .f8…G…Va.
0090 - 14 e3 a6 46 3e ed 2c 09-de bd 60 6d 61 c5 4f 67 …F>.,…`ma.Og
00a0 - bc bb 56 1d 55 81 a1 b6-9f e3 f0 a6 2f 4a 6f 99 …V.U…/Jo.
00b0 - e9 cc 9a 44 05 11 61 56-3f 75 32 4b 63 f1 c1 37 …D…aV?u2Kc…7
Start Time: 1439802866
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
And the last error seems to be the culprit. Did some Googling and the error seems to appear if the root certificate of the chain might not be in the local database of trusted certificates. So I manually imported the root certificate:
Was still getting the error so I did this too for both the intermediate certificates and I still get an error. What could possibly still be going wrong?
Ah, the open ssl tool apparently doesn’t know where to look for the root certificates unless you tell it to. When I point to the folder containing the root certificates it works:
osmc@osmc:~$ sudo openssl s_client -connect synology.example.com:5006 -CApath /etc/ssl/certs
CONNECTED(00000003)
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, CN = synology.example.com
verify return:1
Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=synology.example.com
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
1 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
I checked the /etc/httpd/logs/webdav_error-log file on the NAS and found the following lines:
[Sat Aug 22 19:25:09 2015] [warn] RSA server certificate CommonName (CN) `synology.example.com' does NOT match server name!?
[Sat Aug 22 19:25:10 2015] [warn] RSA server certificate CommonName (CN) `synology.example.com' does NOT match server name!?
[Sat Aug 22 19:25:10 2015] [notice] Apache/2.2.29 (Unix) DAV/2 mod_ssl/2.2.29 OpenSSL/1.0.1p-fips configured -- resuming normal operations
So also on my NAS side I see an error that prevents it from connecting. After some research it appeared to be a missing ‘ServerName’ variable in the httpd-ssl.conf-webdav file (an extra config file on top of the httpd.conf specifically used by Synology). After adding the new hostname it and httpd -k restart it, it started working like charm.
Nice detective work! Glad to see that there was actually an issue on the NAS side and not a bug in OSMC.
While it might have worked with some other clients different SSL libraries have different degrees of “fussiness” about the certificates and SSL connection, so what works for some clients is not necessarily fully correct…