As you can see in the Qualys SSL Test for caldav.hostpoint.ch, the certificate chain is incomplete. Please ask your provider (hostpoint.ch) to include the intermediate certificate "GeoTrust SSL CA" in the server's SSL configuration as it's not included in Android, maybe referencing this issue report.
Thank you, that helps me a lot... too sad, that support at my hoster is
soooo low level.
2014-07-15 12:26 GMT+02:00 rfc2822 firstname.lastname@example.org:
...sorry for my question, I know it is "my" personal problem, but.. please
give me a little hint: is this caused by a buggy .htacces file (or in other
words: something a normal privileged user can influence) or is it the
hoster who did something wrong and/or weird?
I can't tell you It can be anything. 501 is often caused by .htaccess
misconfiguration, but there are thousands of other possible reasons. I'd
first test "normal" HTTPS and DAV without HTTP, then combine it. Don't
forget to make sure the required HTTP methods for DAV (OPTIONS, PROPFIND,
GET, PUT, DELETE, REPORT, [PATCH]) are allowed.
Reply to this email directly or view it on GitHub
Everyone here is irrationally focused on the authenticity of the remote server.
Android cert handling SUCKS.
So... You don't have any choice. Reread the code. Add to it... Don't forget Subject Alt Name. Check the hyperlink I gave here for more fuel to "get the job done."
All public internet services are already compromised (e.g. The Lavabit case already proves that the remote servers... e.g. Google, et al,... are already compromised. The Public CAs controls your keys. Most people here don't even know how the keys work -- it's magic.)
CONCLUSION: Private CAs are the ONLY certificates that can be trusted.
I'm tired of all the dribble about MITMs. That requires a HIJACK -- "perps" need to hack your DNS, set up a fake server, set up fake certs, etc. PRIVATE SYSTEMS AREN'T WORTH THAT EFFORT. Google just gives "anyone" a copy of the keys. You don't even have to worry about fake certs -- because the certs are copies that Google gave them. People are clueless. Including coders
There is nothing more dangerous than transmitting your password in the clear.
"Discussing the obvious" for 8 months is not "working together on the issues."
There is only one issue: Encryption that is easy to use without a graduate degree in operating systems and crypto.
arf! I was checked twice. Thank you for you help.
I used https://sslcheck.casecurity.org/ to verify my certificate chain. The site is based on ssllabs but have a better display than ssllabs. I was an issue with the StartSSL CA certificate.
As the other applications (owncloud, "CardDav-Sync free" and "CalDav Sync Adapter") are able to behave like web browser, it's not so easy to investigate the problem.
Could you update the FAQ http://davdroid.bitfire.at/faq/entry/cannot-verify-hostname in order to add one bullet per issue that we have to verify and for each point specify some guide lines? For example, how we can use the SSL testing service to check the certificat supply chain (or openssl command line).
Is it possible that DAVdroid returns a better error message? ('certificat supply chain error', 'self-signed certificate not allowed', etc...)
Anyway, thank you very much for your support.
Now, DAVdroid is able to connect my owncloud server
I have implemented layered SSL/TLS connections, but unfortunately, the benefits of TlsSniConnectionFactory, namely support for SNI and TLSv1.2 on Android <= 4.4 is not available for HTTP-proxied SSL/TLS connections at the moment.
Implementing this would require to use SSLCertificateSocketFactory.getInsecure() and custom certification management.
I am so very sorry, it is incomplete! Browser didn't complain. It's been broke almost two weeks. It'll be fixed this evening. Again, so sorry for the bogus report. Thanks for the test site though, should be handy to keep mistakes like that from happening.
rfc2822 email@example.com wrote:
@djlucas: Your certificate chain is incomplete, see
Reply to this email directly or view it on GitHub:
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Just for completeness: On Apache you would rename the conf file so that the site you wish to be the base site comes first. So, in /etc/httpd/conf.d I have:
So I renamed owncloud.conf to aa_owncloud.conf so the listing now looks like
and now the correct certificate (after restarting apache) is delivered to non-SNI capable clients. Happy days. Perhaps I could put this info in a wiki somewhere. Is there one? I spent ages trying to get SSL to work with a self-signed cert before I read the entry in the FAQ about SNI support.
@rfc2822 I've read this part of the configuration instructions, but perhaps it's the way I import the certificate that's wrong ? Here how I do :
I display my site on https, Firefox warns me the certificate is unknown, I display the certificate and export it in DER format, with an CER extension. Then I install this file in the security/parameters of android, which tells me the certificate is installed.
Then I try to see my certificate in the user tab, but... nothing (I haven't verified before...).
Edit : I've created a new certificate following the link https://wiki.debian.org/Self-Signed_Certificate (that's not that way I created the former one...), but... THANKS !!! It's ok now