@phy25 said in does not send requests at all to my host:
Maybe you can try entering https://example.com/webdav/user in your browser to see whether it works. Seems like a SSL error, and maybe you can check your network (try different WiFi / mobile data) and the server SSL configuration.
SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
It works fine in the browser, as far as I can tell (see also first paragraph of my post above for a bunch of other urls that work).
Also when I curl:
$ curl -i https://user:email@example.com/webdav/user/caldav
HTTP/1.1 200 OK
Date: Tue, 21 Mar 2017 19:53:43 GMT
Last-Modified: Tue, 21 Mar 2017 11:24:31 +0000
PRODID:-//Radicale//NONSGML Radicale Server//EN
@jeronemo said in Untrusted Certificate at Account Setup:
Yes, but why does it show me then this certificate? Can I trust it?
Because it cannot be trusted automatically. You have to verify it to know whether you can trust it. Please ask your admin (or whoever has used CAcert for your server) for more information.
@Alela It seems that the SSLLabs Android ciphers refer to the default browser (Chrome?) on those platforms, which has a separate TLS stack which is not the system stack.
DAVdroid can only use the system stack. You can find a list of cipher which is supported by the Android default TLS stack in the SDK docs: SSLEngine (Default configuration for different Android versions).
is there any update in this topic ?
Due to security reasons, my owncloud is only accessable via client certificates . Currently all requests from my smartphone (Android 6) are rejected, even if i am able to access the server with chrome. (Chrome supports client certificates)
If you need a test environment, i can set up a testserver for you.
I changed networks a couple of times and at some time the device even had no connection at all. The notification stays. Seems to be the same with another device, one is Android 6 and one is 5.
But I tested, at least it syncs regardless of the notification, when internet connection is established again.
@ctgcwiqc said in Pin not require after importing SSL cert?:
Well this is weird. I don’t use CAdroid. I place SSL cert in webserver root. Navigate to it via web browser, then download and add to trusted credentials. This is how I have always performed this on my phone since initially I believe some time ago CAdroid did not like self signed certificates.
CAdroid is only a helper for the Android certificate import process. It downloads the certificate from a HTTPS server, saves it in the format required by Android and then calls the Android “Import certificate” dialog.
Android didn’t like self-signed certificates without CA flag. So, CAdroid shows a warning for certificates without CA flag, because they won’t work with most Android devices. Nothing more. So, if you can import your certificate using a browser, you can also import it using CAdroid, and the other direction.
However, this is only required if you need the certificate to be valid for all system apps (e.g. email app, etc.). If you import a certificate, it will be valid for all apps, including DAVdroid. However…
Is it possible to accept self-signed cert in DavDroid?
… if you only use the certificate with DAVdroid, there’s no need to import it. DAVdroid handles self-signed certificates on its own using MemorizingTrustManager. So, if you connect to a server and add the certificate in DAVdroid, it won’t show up in the system/user certificates, because only DAVdroid knows that its valid and stores it in its own keystore (<davdroid>/KeyStore/KeyStore.bks).
I do not see the cert in my user trusted credentials on the tablet. I don’t believe I set this connection up via http, but cannot see how to check short of removing the account. Let me know if there is a way to check if this connection (account) web address without removing account.
I don’t know what you mean. What exactly do you want to check?
Thanks. BTW paid for app (davdroid) in play store. This app is looking good design wise. Thanks.
Appendix (Back to English
May be the information from ssllabs about WebView and WebView for Android - Google Chrome is informative, at least it is an explanation (for me).
Indeed, line 66, I read : “TLS_ECHDE_RSA_WITH_AES_128_GCM_SHA256”,
Unlike the other lines, where I read ciphers names with “ECDHE” inside.
Of course it has to be ECDHE (elliptic-curve Diffie-Hellman ephemeral) and not ECHDE. Will be fixed in future versions (although it only applies to Android 4.x devices). In the meanwhile, I suggest to allow CBC (and not only GCM).
Ok, seem I resolved my SSL certificate problems, despite the CA-Flag.
At sometime finding the bug i disabled the StartCom certificate in the System Settings.
Enabling it and going through accept permanently dialogs seems to fixed it.
Calender gets synced again. .-)
I have a problem after upgrade my DAVdroid application on FDroid (i was some versions before last one)
My certificate isn’t accepted by DAVdroid anymore since the upgrade.
I run Baikal on my Raspberry Pi at home and don’t have DNS (don’t need)
Before it worked fine, Now i have this message:
"Le serveur n’a pas pu s’authentifier comme “xx.xxx.xxx.xxx”. Le certificat est valide uniquement pour:
CN=xx.xxx.xxx.xxx, O=YYYYYYYY, ST=MaVille, C=FR
Voulez-vous vous connecter quand même?.."
I have CAdroid installed to import the certificate, i uprade it the same time as DAVdroid and it didn’t worked too after that to fetch my certificat.
I have to get the previous version of CAdroid back to fetch successfully my certificate.
But i can’t get the version of DAVdroid i got before on FDroid…
Sorry for my english.
@devkid DAVdroid 0.8 didn’t use okhttp, thus it didn’t support HTTP/2 / SPDY.
Now it does, but it doesn’t work with your server. How can you know that DAVdroid is the problem? I have heard this argument (“everything worked before”) about 10.000 times, and in 9.999 times the problem was not DAVdroid.
I’m interested in getting these things working and I don’t know whats the cause of your problem, but “it worked before, now it doesn’t, so there’s a DAVdroid bug, fix it” is not an accurate bug report and it won’t help getting these things working.
Thanks for your suggestion. While I don’t think it makes sense to not trust system-wide CAs on app level (if you distrust those CAs, wouldn’t they have to be removed/disabled in the system so that they can’t do any harm in other apps, too?), I certainly support that certificate pinning would be a good thing.