I guess your suggestion would be a good idea, but as the sync is triggered by Android, I don’t see any chance, so I’ll close this for now.
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 firstname.lastname@example.org 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?