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, 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

    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

    Anyway, both are root CAs present in my Android 4.1.2 device, so I’m wondering what’s going wrong. According to, 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”.

    Some observations:

    • 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

    Could any of this be the reason why this isn’t working?
    (I’m happy to provide more information if needed!)

  • developer

    The certificate is for the ISP’s domain name and wildcard subdomains, but not explicitly for the given subdomain with the ownCloud installation.

    I guess this may be the reason. DAVdroid uses the BrowserCompatHostnameVerifier. Docs say:

    »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 “*”) with BROWSER_COMPATIBLE matches all subdomains, including “”.«

    Does the wildcard domain match your subdomain correctly? Does it work in browsers?

  • Yeah, the wildcard is just (analogue to) *, so it matches (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).

  • Yup, says something like

    Server Key and Certificate #1
    Common names *
    Alternative names *
    Prefix handling Not required for subdomains


  • 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?

  • developer

    Can you send the domain name to 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?

Similar topics