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

xyzzy

My groupdav-server is behind a client certificate authenticated webserver but still needs username/password. I tried using davdroid’s client certificate option and
https://user:password@domain
for the base URL, but that doesn’t work as well

marki

Hey, in fact what we need is both.

First certificate based auth for the SSL connection, then the usual username/password inside the HTTPS “tunnel”.

Is that possible?

The reason for this is that the options of our backend are limited. What we do with Davdroid is to connect to a reverse proxy that allows us to add/mangle stuff that the client sends. In this case we would like to add a client certificate for overall access to the reverse proxy, and then continue as usual with username/password for the actual Caldav/Carddav connection (as it is not possible to have TWO http-based authentications going on one after the other for example).

Well, if you are currently implementing this, then please keep that scenario in mind.

diener

This is more of a “me too” but it would be nice if an implementation for this worked with the system-wide user certificate management.

Den

rfc2822

@diener What do you mean? The client certificates used by DAVdroid are taken from the system-wide user certificate management.

xyzzy

@marki

I have the same problem as you. My groupdav-server is behind a client certificate authenticated webserver but still needs username/password. I tried using davdroid’s client certificate option and
https://user:password@domain
for the base URL, but that doesn’t work as well

rfc2822

At the moment, DAVdroid only supports username/password or client certificates as authentication, but not both because client certificates are implemented as an authentification method.

I recommend to use client certificates for authentication.

xyzzy

I neither change the authentication method of the groupware server nor the certificate requirement of the proxy server before the groupware server. For me it would be good enough if I could specify user/password in the base url. But davdroid seems to remove this part of the url.

rfc2822

@xyzzy said in Support for SSL client certificate and Basic/Digest at same time:

I neither change the authentication method of the groupware server nor the certificate requirement of the proxy server before the groupware server. For me it would be good enough if I could specify user/password in the base url. But davdroid seems to remove this part of the url.

It doesn’t remove anything, but it doesn’t use username/password from the URL. At the moment, DAVdroid unfortunately only supports username/password or client certificates as authentication, but not both because client certificates are implemented as an authentification method.

BTW, I cannot reply using firefox 59.0.2. In the webconsole I get:

I’m typing this reply with Firefox 59.0.2 (MozillaFirefox-59.0.2-lp150.1.6.x86_64 from OpenSUSE Leap 15 Beta). If you can find out what the problem is, it would be kind if you could report it to NodeBB directly. We’re currently using NodeBB 1.8.2 (latest release) without modifications.

dg10a

@rfc2822 Any update on using client certificates with username and password authentication? I’m in the same situation as above, where the reverse proxy requires the client certificate and the DAV server requires username and password authentication. There doesn’t seem to be a way to disable the username and password authentication for any of the implementations I’ve tried (NextCloud, Radicale, Baikal).

rfc2822

@dg10a You could write an authentication plugin for Radicale, which authenticates against the certificate: https://radicale.org/plugins/

dg10a

Not sure I’m following. The certificate is authenticated at the reverse proxy level, before any traffic reaches Radicale.

rfc2822

@dg10a You could then pass the authentication info to Radicale (simply said: pass /originalPath?$originalArgs&authenticatedUser=MyUserFromCertificate) and evaluate it with a custom plugin

marki

@rfc2822 I guess the point still is that you can use either a certificate or HTTP basic auth, not both.

rfc2822

@marki Yes, these are two different topics:

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

marki

@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.

dg10a

@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.

marki

@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.

dg10a

@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.

rfc2822

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:

Service discovery (email) + password
URL (+ service discovery) + password
Service discovery (email) + client certificate
URL (+ service discovery) + client certificate
Service discovery (email) + password + client certificate
URL (+ service discovery) + password + client certificate
In the future: OAuth
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

marki

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).

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

Similar topics

[Feature Request] Allow to get Address and Credentials from qrCode
Ideas, future talk, development • enhancement • • Mannshoch

Request change VTODO parsing errors to be non-fatal / improve logging
Ideas, future talk, development • solved • • ccoenen

Allow to define a time windows for synchronization
Ideas, future talk, development • enhancement • • j-ed

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

Similar topics

[Feature Request] Allow to get Address and Credentials from qrCode Ideas, future talk, development • enhancement • • Mannshoch

Request change VTODO parsing errors to be non-fatal / improve logging Ideas, future talk, development • solved • • ccoenen

Allow to define a time windows for synchronization Ideas, future talk, development • enhancement • • j-ed

[Feature Request] Allow to get Address and Credentials from qrCode
Ideas, future talk, development • enhancement • • Mannshoch

Request change VTODO parsing errors to be non-fatal / improve logging
Ideas, future talk, development • solved • • ccoenen

Allow to define a time windows for synchronization
Ideas, future talk, development • enhancement • • j-ed