@rfc2822 Thanks for the hint! The automatic conflict resolution didn't worked in our project, since there was a dependency in cert4android, that we hadn't in our module. After adding com.android.support:cardview-v7 as dependency to our module, the conflict resolution works, now.
Hence, the problem is solved without updating cert4android. Thank you very much!
The connections never got past TLS negotiation so there is no chance that a well-known URL or a redirect could have been given by the server and there are none defined on that 12345 port URL hierarchy anyway. Also there are no related SRV records in the DNS.
I tried again and looked a bit further into the data streams. It looks like the server configuration had limited cipher suites so that no common suite was found between DAVdroid and the server on port 12345. The client tried twice, both times ending in the server sending a TLS alert due to cipher suite mismatch. After that I see a DNS SRV query for _carddavs._tcp.server.name.here.invalid which is answered with no such name (nxdomain). Immediately after that traffic to port 443 starts and the note about invalid server cert on port 443 is shown. The cipher suite configuration on port 443 has been compatible enough all the time, so a handshake to that port goes far enough to return the certificate.
I loosened up the acceptable cipher suite list on the server on port 12345 enough to include a cipher suite sent by DAVdroid in the client hello and now it works. Pretty weird / misleading user experience.
Anyway thank you for your work on DAVdroid! Not having native DAV synchronization is a significant deficiency in Android, DAVdroid seems to be filling that gap nicely.
I think that you can switch back to your old notation using 26.+ (if you really want), since you've added the new Google maven repository.
However, you have the same "problem" with the build tools. And for both cases, Android Studio should notify you in case of updates. Unfortunately, there was no notification for the new maven repository.
@mrtuple Protecting against MITM with accepted certificates (either manually or by PKI) is not within the scope of DAVdroid. It would also mean that Basic auth would have to be disabled completely.
TLS is already a way to protect the connection – in my opinion, there's no need to implement "TLS in TLS". "Rogue IT staff" could see all private data (= not only passwords, but also events, tasks etc.) even when using Digest auth. It would also mean that Web-based logins over TLS (like every online bank uses it) is insecure.
But now this is a discussion about whether TLS connections are secure and whether Basic auth is evil, and I don't want to make these topics a discussion about DAVdroid.
Update: Maybe we should create an off-topic / general discussion forum for such things? What would you think?
So with that option commented out it's working fine, I'm on 126.96.36.199-ose from f-droid and android 7.
Apparently Android 7 supports only up to secp256r1, this was supposedly fixed in 7.1.1.
Aside that, a bit of a rant, why are gitlab issues not enabled and instead this forum is used as a bug report tool? I have to create yet another account and wade through 5 google captchas just to write this.
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.
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.