DAVDroid 1.1.1 / self-signed cert, needs manual update



  • Hi,

    After upgrading to 1.1.1 via f-droid, DAVdroid did not connect to my server via SSL and self-signed certificate, registered on the phone as trusted CA. I had to manually confirm the certificate to get it back working. No such problem using 1.10.1.1. If this is intended, I'd suggest a warning in the release notes.


  • developer

    Hello,

    I assume you mean 1.11?

    Are you absolutely sure that this is caused by DAVdroid and not a relation only in time (like a new certificate on the server)?

    I'm asking because there have not been any changes in certificate handling and we didn't see this behavior in our tests.

    If you're sure that it's caused by DAVdroid: Which cert provider are you using? Is the cert still valid? Can you provide more details and/or steps to reproduce?



  • Hi,

    I have the same issue with all devices I use: Since a DAVdroid update some month ago (via fdroid, it probably was 1.11...) I had to manually accept the certificate, although I added the CA's certificate to the system (which worked before).
    Other apps (like the nextcloud APP) are still working correctly. I also manually checked the correctness oft the CA's certificate by a "curl --cacert...".
    Do you need some logs etc?

    pasdVn


  • developer

    Hello,

    @pasdvn said in DAVDroid 1.1.1 / self-signed cert, needs manual update:

    Do you need some logs etc?

    Of course 🙂 And/or a publically accessible test account, so that I can give a try.

    Maybe the host name or expiration date is incorrect?

    Which CA do you use?

    Please provide as many details as possible.



  • Ok - I double checked and debugged that on my own :):
    The problem is, that okhttp changed its verification behavior with cd84d79c3574de81f23802f832f2ead6ad38a735:

    The use of Common Name was deprecated in RFC 2818 (May 2000), section 3.1:

    Although the use of the Common Name is existing practice, it is
    deprecated and Certification Authorities are encouraged to use the
    dNSName instead.

    In 2017, Chrome 58, Firefox 48, and Opera 45 web browsers removed this
    fallback, with Chrome leaving it configurable for enterprise deployments
    (see https://www.chromestatus.com/feature/4981025180483584).
    Android is removing it in http://r.android.com/581382 .

    The okhttp version was updated within dav4android with 1169e15017a900d7fb3f29e42ea18d45e3c5d33a.

    I generated my server-side certificate without any X509 extensions and just gave the common name (CN, -> the domain name) in the certificate, something like:

    openssl req -new -key key-for-webserver.pem -out www_sign-request.csr -sha512 # and than entering all the stuff interactively...

    So I need to generate a new certificate with a subject alternative name (e.g. like described here - for people with the same problem as me). I'll do that and hope that it is than working again.

    Nevertheless I wonder why e.g. Firefox does not have a problem with this certificate, as the above commit note says the "fallback"- verification by the CN is removed with version 48 of FF...


  • developer

    @pasdvn Thanks for the update!