Support for SSL client certificate and Basic/Digest at same time

  • developer

    @marki Yes, these are two different topics:

    1. Use two authentication methods (client-certificate authentication and user name/password) at the same time with DAVdroid
    2. How to use client-certificate authentication with a common server, like Radicale

  • @rfc2822 Hmm, from what @dg10a wrote (“There doesn’t seem to be a way to disable the username and password authentication…”) I guess this was about 1)?

    As far as 2) goes that would only work if the backend CalDAV server supported some mode where you could just tell it “trust me, I’m user XXX, go”. In that case you would use the reverse proxy as a trusted source and just send the required data somehow using HTTP as you have shown. Albeit, not all CalDAV backends support such a thing.

  • @rfc2822 Thank you, I will look into writing a plugin. However, I think #1 is my preferred solution as it is server agnostic (as @marki mentioned) and does not require the reverse proxy to treat particular applications differently.

  • @dg10a #1 is also more secure. First, it authenticates the device (certificate), then it authenticates the user (password). It would be so elegant. ^^
    Now I’m not sure what you’re planning to do. I hope you’re still using an encrypted private key and you’re not just asking for no credentials anymore. If you’re doing that, you might as well just save the password.

  • @marki I was asking about disabling user/pass authentication to be able to test client certificate authentication in the current DAVdroid build. My ideal setup would be as you described, with the device authenticated via certificate and the user via password.

  • developer

    I have created a new thread for that.

    Technically, username/password together with client certificates are not that hard. As always, the UI part is more difficult.

    All these possiblities:

    1. Service discovery (email) + password
    2. URL (+ service discovery) + password
    3. Service discovery (email) + client certificate
    4. URL (+ service discovery) + client certificate
    5. Service discovery (email) + password + client certificate
    6. URL (+ service discovery) + password + client certificate
    7. In the future: OAuth
    8. Maybe: no authentication at all (yes, this was also requested)

    should be grouped in a way that makes sense (and is “material”), and for the most common methods (printed bold above), there should be as little distraction as possible (no talking about strange “certificates” etc. when you choose one of these two methods). Maybe hide everything then 1+2 behind some “expert” button?

    It should be possible to change the credentials in the account settings, like now. Maybe it would make sense to change the authentication method, too? For instance, could you change from username/password to client certificates without password at all? In this case, the username/password field would have to disappear.

    I guess the whole login activity should be re-worked and probably “materialized” (colors, images, whatever). Would be nice if someone could provide a good draft for the login fragments 🙂

  • You could probably combine everything like this:


    By default, only “password” is checked. Like that you can choose to either have no authentication at all (“password” is unselected), one of the two, or both (“password” as well as “client certificate” are selected).

    Depending on what is selected, you either show both password and certificate selection at the top (below whatever connection method is chosen), one of the two, or nothing at all (email or username/URL only).

    Maybe you could hide the entire lower part “Authenticate using” behind some “Advanced mode” button.

    Remains OAuth. I’m not sure about that, would have to read up on how it works first (what data is needed to connect).

  • Vote +1

  • admin

    @marki @Tilo-Mey Internally we’ve already thought about this in more detail and basically we’re willing to implement it. However we are thinking of more streamlining the setup options GUI in general and when we finally do this step this feature will also come to DAVx5!

  • I modified the ‘Login with URL and user name’ to allow an optional client certificate.


    The change is for 3.0 and is available at for those who need it now and willing to build their own.

  • @Patrick-Lai That mock-up looks encouraging. I don’t see a merge request at the bitfire gitlab, though. Are you going to submit it?

    For the record, I am another user seeking client certificate + password support. I connect to an internet-facing reverse proxy that uses client certificates for network access authorization. It passes authorized requests to a DAV service that uses passwords for user authentication. Firefox and Thunderbird (TbSync) handle this fine, but DAVx5 currently does not.

  • @foresto, thank you for your interest. I did not submit a merge request because there was a ‘pipeline’ failure in my GitLab fork. And I did not want to spend much time to investigate as I didn’t feel it would get much traction. That’s partly because of the age of this issue, and partly because my change might not fit DAVx5’s UI plan (e.g. per this comment by @devvv4ever).

    Anyway, my change is against v3.0 and so is outdated. Not sure how much work would be required to bring it up to current DAVx5 version.

  • Some has requested access to my code and I’ve granted it. So hopefully we can see some progress.

    Besides update to the current DAVx5, I think the label of the “SELECT CERTIFICATE” button needs to be changed to indicate it is optional, or it may be confusing to users. (If we had more options we could group have an ‘Advanced Options’ button.)

Log in to reply

Similar topics

  • 7
  • 7
  • 7