So here was the solution for me coming from synology assistance (Malek was super nice to help me):
1/ On the NAS, in control panel, “external access”, tab DDNS : create a synology address… it will be something like that: <name>.synology.me
2/ On the NAS, Set a fixed ip address on the local network to the nas : to do that, go to control panel/network/tab:network interface and modify the LAN line “manual ip config” the line IP address with the number you want (for me 192.168.1.24)
3/ on your box, open ports 5001 (connect to it through its local address and modify its NAT configuration. open a port for your nas in TCP port 5001
so here, the nas is accessible fro the outside on its caldav
4/ on the android DAV5X, open it, add a account, select URL and there add put the URL: https://<name>.synology.me:5001/caldav/<your_id>/aiioyb/
and enter your <your_id> and your password (the one to connect to your nas, at the id session).
Cannot connect to https server with good certificate
I’m trying to connect DAVDroid 0.6.1 to a client’s ownCloud installation, which is hosted on (a subdomain of) their ISP’s server. I’m getting the “I/O-Error: Cannot verify hostname” error and have read through the corresponding FAQ entry.
The thing is: that server validates just nicely with https://www.ssllabs.com, getting grade A- (the minus is for “not supportting Forward Secrecy with the reference browsers” – but that’s nothing that would cause DAVDroid to not work, right?).
Certificate #1 was issued by RapidSSL CA (SHA1withRSA, 2048 bits key length) and is shown as trusted by ssllabs.com.
There are two certification paths, one ending at GeoTrust Global CA (SHA1: de28f4a4ffe5b92fa3c503d1a349a7f9962a8212, RSA 2048 bits / SHA1withRSA), the other one at Equifax / Equifax Secure Certificate Authority (SHA1: d23209ad23d314232174e40d7f9d62139786633a, RSA 1024 bits / SHA1withRSA), the Equifax one being noted as weak because of their 1024 bits key length in Mozilla’s trust store, according to ssllabs.com.
Anyway, both are root CAs present in my Android 4.1.2 device, so I’m wondering what’s going wrong. According to ssllabs.com, TLS 1.0, 1.1, and 1.2 are supported, as well as SSL 3. Their handshake simulation with both Android 4.1.1 and 4.2.2 gives “TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) FS 256”.
- The certificate is for the ISP’s domain name and wildcard subdomains, but not explicitly for the given subdomain with the ownCloud installation.
- The subdomain contains numbers, a does the second level domain (think oc123.example1.com).
Could any of this be the reason why this isn’t working?
(I’m happy to provide more information if needed!)
The certificate is for the ISP’s domain name and wildcard subdomains, but not explicitly for the given subdomain with the ownCloud installation.
»The HostnameVerifier that works the same way as Curl and Firefox.
The hostname must match either the first CN, or any of the subject-alts. A wildcard can occur in the CN, and in any of the subject-alts.
The only difference between BROWSER_COMPATIBLE and STRICT is that a wildcard (such as “*.foo.com”) with BROWSER_COMPATIBLE matches all subdomains, including “a.b.foo.com”.«
Does the wildcard domain match your subdomain correctly? Does it work in browsers?
Yeah, the wildcard is just (analogue to) *.example1.com, so it matches oc123.example1.com. (Currently re-running the ssllabs test just to make sure.)
Connecting to the server works with both current Firefox and Chromium versions (Ubuntu 14.04).
One more observation, the little lock icon left of the URL bar is grey (while e.g. for GitHub it’s green), and clicking on it says something like “This website is being operated by (unknown)”
So apparently the certificate doesn’t include any information about its owner… Is that a problem?
Can you send the domain name to email@example.com please?
I’m extremely embarrased - seems like I had mixed up those numbers (4 digits) in the subdomain when entering the hostname in DAVdroid, while on my desktop system, I was always using the right one (thanks to the browser’s history, that is). I’m very sorry - it was a mere typo.
One minor suggestion, my client included “https://” when entering the hostname (as do a lot of people, I think), and the error message isn’t very specific. So could you either issue a more specific one or just automatically remove that part?