SSL and TLS errors when trying to connect to davs:// (WebDAV HTTPS) source

Hi guys,

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?

Thanks very much for your help in advance.

Kind regards,

Skeetneet

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 :wink:

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 :smiley: so the cert is definitely bogus. Update the firmware on the NAS or check the support forums for the NAS for a fix.

Hi DBMandrake,

Thank you for replying to my post and helping out, much appreciated. :relieved:

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 :wink: 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.

What could be going wrong here?

Are you sure your NAS supports at least TLS 1.0, and is not relying on SSL3 ?

Many (but not all) TLS client libraries now block SSL3 since a security hole was found in it a few months ago.

Also silly question, but are you sure port 5006 is using TLS and is not just plain HTTP ?

Yet another silly question - why are you using webdav over TLS to a local NAS instead of NFS or SMB, which are much better suited to the task ?

Obviously the certificate you received is invalid (out of date). Some things to consider:

  • Do you use a different domain, or IP to resolve the NAS? It may use SNI to determine which certificate is to be used, and thus vary.
  • Perhaps your other clients have different supported encryption levels. Try:

wget --secure-protocol=auto https://mysynology.example.com:5006 -O /dev/null

wget --secure-protocol=SSLv3 https://mysynology.example.com:5006 -O /dev/null

wget --secure-protocol=TLSv1_2 https://mysynology.example.com:5006 -O /dev/null

One of these will likely fail.

Sam

Hi guys,

Thanks again for replying.

@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:~$ wget --secure-protocol=auto https://mysynology.example.com:5006 -O /dev/null
converted ‘https://mysynology.example.com:5006’ (ANSI_X3.4-1968) -> ‘https://mysynology.example.com:5006’ (UTF-8)
–2015-08-17 09:08:24-- https://mysynology.example.com:5006/
Resolving mysynology.example.com (mysynology.example.com)… 81.148.62.117
Connecting to mysynology.example.com (mysynology.example.com)|81.148.62.117|:5006… connected.
GnuTLS: A TLS warning alert has been received.
GnuTLS: received alert [112]: The server name sent was not recognized
ERROR: The certificate of ‘mysynology.example.com’ is not trusted.
ERROR: The certificate of ‘mysynology.example.com’ hasn’t got a known issuer.
osmc@osmc:~$ wget --secure-protocol=SSLv3 https://mysynology.example.com:5006 -O /dev/null
converted ‘https://mysynology.example.com:5006’ (ANSI_X3.4-1968) -> ‘https://mysynology.example.com:5006’ (UTF-8)
–2015-08-17 09:09:23-- https://mysynology.example.com:5006/
Resolving mysynology.example.com (mysynology.example.com)… 81.148.62.117
Connecting to mysynology.example.com (mysynology.example.com)|81.148.62.117|:5006… connected.
GnuTLS: A TLS fatal alert has been received.
GnuTLS: received alert [40]: Handshake failed
Unable to establish SSL connection.

So I requested the details on my certificate:

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

Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=mysynology.example.com
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
-----BEGIN CERTIFICATE-----
MIIGRjCCBS6gAwIBAgIRAMKiyPMFEc4OP2OF3ZLe8WAwDQYJKoZIhvcNAQELBQAw
gZAxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTYwNAYD
VQQDEy1DT01PRE8gUlNBIERvbWFpbiBWYWxpZGF0aW9uIFNlY3VyZSBTZXJ2ZXIg
Q0EwHhcNMTUwODE0MDAwMDAwWhcNMTgwODEzMjM1OTU5WjBPMSEwHwYDVQQLExhE
b21haW4gQ29udHJvbCBWYWxpZGF0ZWQxFDASBgNVBAsTC1Bvc2l0aXZlU1NMMRQw
EgYDVQQDEwtuYXMuZXJhcy5udTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoC
ggIBAPfVSmrRQKwqGWhm9bPiRbyS4VuHigEDoaDkw4EkskNkz6FOyleVljcZlWcI
GNG79MXwW0yNzxkjF8EXfXboXd3pMQ9vpCCoN779Tdu6cxPie2MyKNscgqbArPaa
4TttmNpYEkTTm88FOXGOKum/7A7/rafnxjGs3NJaSAPakIoOdBanP2Z0nWvdskpB
ETfKxwem2ok+6NB14O+1YFmRoFNAfAZpNw9iN9t3V4FRW5IawNEOVhsEpjNBPUNR
VA6HudWf2GpRdG1i5BTKbyeTES9N7HMnmf/ph/25B13FEVp8cpR/E8J2mqtjomhX
U2P9xo3bRVRQ8EIRWKzoNTEwUasLayKmYSK5LIDp0esrEJs//RB0CZ4AEmlweNcW
6yIkxKs14Jio0MW6+vxGgaS+22MCmrBChA4CxMdOFWHjDxf2WmIq1hyBl7kCR/BO
mp/lawFYFIOxhG8m0F8KyThpmq0mUR1Bq9qFtyECMyMB/1j0OJTD97W4KTVyi1A0
3zk5dIaVKyiB7Rxw/Goy8RFuJGHAV8lL4Gh3vjB4c4E/uFVSnBpvUfAfMKXOT8xO
ncJaDx9NA0G8CbsEEuIzkYm/tuH6StKmLCTY7BE0qCojhfajGSJWR0SrBZsnjpu9
PDtVIIQit/Va8FhYD/SnQs83jqCAU/a9DeD1fv+aXwMjtSyrAgMBAAGjggHZMIIB
1TAfBgNVHSMEGDAWgBSQr2o6lFoL2JDqElZz30O0Oija5zAdBgNVHQ4EFgQUqmmX
A+e40mabS9qqxDQpzCokiIowDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAw
HQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCME8GA1UdIARIMEYwOgYLKwYB
BAGyMQECAgcwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLmNv
bS9DUFMwCAYGZ4EMAQIBMFQGA1UdHwRNMEswSaBHoEWGQ2h0dHA6Ly9jcmwuY29t
b2RvY2EuY29tL0NPTU9ET1JTQURvbWFpblZhbGlkYXRpb25TZWN1cmVTZXJ2ZXJD
QS5jcmwwgYUGCCsGAQUFBwEBHkwdzBPBggrBgEFBQcwAoZDaHR0cDovL2NydC5j
b21vZG9jYS5jb20vQ09NT0RPUlNBRG9tYWluVmFsaWRhdGlvblNlY3VyZVNlcnZl
ckNBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCcG
A1UdEQQgMB6CC25hcy5lcmFzLm51gg93d3cubmFzLmVyYXMubnUwDQYJKoZIhvcN
AQELBQADggEBAB1xNLS9ND/OqeQxS9zUYMfUeAMECDYYvczmp/xBZzUtM93cY2mQ
BjYC8lMJivxrRxZnlAnnetoTkCtE+KgcT8uo9kF1rirQFl+NXjvvLP18VJZuk6Pp
DOYNMvIgaDlkBh14z7DxGhbU3RN0ldGalJM9BNYWb1kV0bUNCTvg2X6zZ0F9VrVI
Aw6KcjRkzKpNNGlRoPbIUmA5PcgdH/ldUDccYNSHCwJSmMULi3ClJQ15meMXSZmr
1mCzGNKrTeTmxilF+Py1VmmbKpT4gSovJG0ZrwIUiuBb2pkUYNXbAhMeuLRMbAJ/
0MT1WfJ6TQPgYgRNhrOaPtS25D0+J++zeoo=
-----END CERTIFICATE-----
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
-----BEGIN CERTIFICATE-----
MIIGCDCCA/CgAwIBAgIQKy5u6tl1NmwUim7bo3yMBzANBgkqhkiG9w0BAQwFADCB
hTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNV
BAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTQwMjEy
MDAwMDAwWhcNMjkwMjExMjM1OTU5WjCBkDELMAkGA1UEBhMCR0IxGzAZBgNVBAgT
EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxNjA0BgNVBAMTLUNPTU9ETyBSU0EgRG9tYWluIFZh
bGlkYXRpb24gU2VjdXJlIFNlcnZlciBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAI7CAhnhoFmk6zg1jSz9AdDTScBkxwtiBUUWOqigwAwCfx3M28Sh
bXcDow+G+eMGnD4LgYqbSRutA776S9uMIO3Vzl5ljj4Nr0zCsLdFXlIvNN5IJGS0
Qa4Al/e+Z96e0HqnU4A7fK31llVvl0cKfIWLIpeNs4TgllfQcBhglo/uLQeTnaG6
ytHNe+nEKpooIZFNb5JPJaXyejXdJtxGpdCsWTWM/06RQ1A/WZMebFEh7lgUq/51
UHg+TLAchhP6a5i84DuUHoVS3AOTJBhuyydRReZw3iVDpA3hSqXttn7IzW3uLh0n
c13cRTCAquOyQQuvvUSH2rnlG51/ruWFgqCAwEAAaOCAWUwggFhMB8GA1UdIwQY
MBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSQr2o6lFoL2JDqElZz
30O0Oija5zAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNV
HSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwGwYDVR0gBBQwEjAGBgRVHSAAMAgG
BmeBDAECATBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNv
bS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcB
AQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9E
T1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21v
ZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAE4rdk+SHGI2ibp3wScF9BzWRJ2p
mj6q1WZmAT7qSeaiNbz69t2Vjpk1mA42GHWx3d1Qcnyu3HeIzg/3kCDKo2cuH1Z/
e+FE6kKVxF0NAVBGFfKBiVlsit2M8RKhjTpCipj4SzR7JzsItG8kO3KdY3RYPBps
P0/HEZrIqPW1N+8QRcZs2eBelSaz662jue5/DJpmNXMyYE7l3YphLG5SEXdoltMY
dVEVABt0iN3hxzgEQyjpFv3ZBdRdRydg1vs4O2xyopT4Qhrf7W8GjEXCBgCq5Ojc
2bXhc3js9iPc0d1sjhqPpepUfJa3w/5Vjo1JXvxku88+vZbrac2/4EjxYoIQ5QxG
V/Iz2tDIY+3GH5QFlkoakdH368+PUq4NCNk+qKBR6cGHdNXJ93SrLlP7u3r7l+L4
HyaPs9Kg4DdbKDsx5Q5XLVq4rXmsXiBmGqW5prU5wfWYQ//u+aen/e7KJD2AFsQX
j4rBYKEMrltDR5FL1ZoXX/nUh8HCjLfn4g8wGTeGrODcQgPmlKidrv0PJFGUzpII
0fxQ8ANAe4hZ7Q7drNJ3gjTcBpUC2JD5Leo31Rpg0Gcg19hCC0Wvgmje3WYkN5Ap
lBlGGSW4gNfL1IYoakRwJiNiqZ+Gb7+6kHDSVneFeO/qJakXzlByjAA6quPbYzSf
+AZxAeKCINT+b72x
-----END CERTIFICATE-----

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:

osmc@osmc:~$ sudo mv AddTrustExternalCARoot.crt /usr/local/share/ca-certificates/AddTrustExternalCARoot.crt
osmc@osmc:~$ sudo update-ca-certificates
Updating certificates in /etc/ssl/certs… WARNING: Skipping duplicate certificate AddTrustExternalCARoot.pem
WARNING: Skipping duplicate certificate AddTrustExternalCARoot.pem
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d…done.
osmc@osmc:~$

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

Start Time: 1439995814
Timeout   : 300 (sec)
Verify return code: 0 (ok)

So the question still remains… how do I get it to work with a davs:// source from xbmc?

Fixed it!

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…