Support for SSL client certificates

My server requires SSL client certificates for authentication, so it would be nice to have that feature in davdroid.
If nobody wants to implement this feature, I’ll be glad to help out with it, but I’d have to talk with a project manager beforehand I guess.

I just happend to work on this recently. Please have a look at stephanritscher/davdroid@d1508df5277f474ee71f8e6fd899483a22b01c6a. There are some explanations of the current status in the first comment of the commit.

if you add the CA’s certificate of the /server certificate/ to the
Trusted credentials storage, this means that the client (your Android
device) trusts the authenticity of the server. This is a very common use
case.

I was speaking about another use case, rather common in enterprise
setups. Here both, the /client/ and the /server/ do have certificates to
prove their authenticity. Handling the /server/ certificate is done as
above. Additionally, the /client certificate/ has to be configured in
the client including the private key of the certificate (this is what
ticket #266 is about) and to the server (which can be done by making the
CA’s certificate of the /client certificate/ trusted for the web
server). If the client fails to provide a /trusted client certificate/,
the server will refuse the connection.

I hope this helps for your understanding.

Best regards,
Stephan

On 08/15/2014 10:47 PM, dirdi wrote:

I do not see a need for such a feature: Just add the CA’s root
certificate to your android’s /Trusted credentials storage/. This
works fine for me.

of course you are absolutely right. I am familiar with client
certificates but i misread the TS and thought he wants to connect to a
server with a certificate signed by his own CA. However, i noticed my
mistake after i posted the comment and deleted it right away. Now the
thread is a bit messed, but this post should explain why

I’m sorry for the inconvenience,

dirdi

On 08/15/2014 11:02 PM, stephanritscher wrote:

Hi dirdi,

if you add the CA’s certificate of the /server certificate/ to the
Trusted credentials storage, this means that the client (your Android
device) trusts the authenticity of the server. This is a very common use
case.

I was speaking about another use case, rather common in enterprise
setups. Here both, the /client/ and the /server/ do have certificates to
prove their authenticity. Handling the /server/ certificate is done as
above. Additionally, the /client certificate/ has to be configured in
the client including the private key of the certificate (this is what
ticket #266 is about) and to the server (which can be done by making the
CA’s certificate of the /client certificate/ trusted for the web
server). If the client fails to provide a /trusted client certificate/,
the server will refuse the connection.

I hope this helps for your understanding.

Best regards,
Stephan

On 08/15/2014 10:47 PM, dirdi wrote:

I do not see a need for such a feature: Just add the CA’s root
certificate to your android’s /Trusted credentials storage/. This
works fine for me.

Hi,
I have a shared server hosting with OVH.
I have no certificate for my website, because there is a certificate only for the cluster, which is not linked to individual site names.
Wen I try and set up the connexion on my Galaxy S3, it’s written: ‘cannot verify hostname’.
I can’t get a self signed certificate to work, I tried to put one in the device, but it doesn’t change anything.
When I replace my website name by the cluster name (which has a certificate), I get: ‘Invalid DAV response, no Cavdav available’.
What can I do ?

@mmonaco: @stephanritscher has this in his fork, which I am currently using for this reason. Would be nice however if this would be supported in the official version. Maybe file a pull request for this feature stephan?

@rfc2822 I use nginx+baikal (based on SabreDAV). Sorry, I cannot give you a test account at the moment (you would need a certificate from the specific CA). If I find time, I could set up a test server, but that would take more effort than I can currently afford.
The code @stephanritscher provided does work like a charm for my system.

Note that the SSLCACertificateFile CA doesn’t have to have anything to do with your server CA. So if you have your own server with a cert signed by a real CA like StartSSL, the client options don’t affect anything.

i’m running radicale caldav/carddav server (version 0.9) on an internal machine. for external users i’m providing secured access using stunnel4 service on the gateway. thus i don’t have to care about the ssl stuff for all the internal services (caldav/carddav and imap/smtp as well), but only have a centralized configuration on the gateway (stunnel server). the following code shows an example for the radicale caldav/carddav serice, which runs on tcp/5232 (default):

It’s just ssl-offloading with client certificate check in addition, which is fully transparent for the back-end services.

ca, client and server certificates and crl as well can be generated using the easy-rsa scripts provided by the openvpn communitiy (as @mmonaco mentioned above). apart from that, xca or tinyca2 may be usefull tools, if you’re looking for graphical ones.

I’m sorry not to be able to provide you a test account, but maybe the information above will help you to set it up on your site with less effort.

are you still in the need for a test setup to integrate the SSL client certificate authentication feature in DAVdroid? We would like to see this feature for our projects, too, and would like to support the development of it.

In our scenario, we use a self-signed root CA. There are intermediate CAs used to sign server and user certificates. The root CA cert and the user certificates are deployed to client devices. The CN stored in the user certificate is forwarded to radicale as the username (FastCGI).

So this is not user authentication with a username and password (htpasswd method), but plain SSL client certificates. Authentication is done by the web server, not the application behind it.

Would be cool if this feature could be implemented by using the OS credential store, so users add their PKCS12 credentials system-wide. When establishing the HTTPS connection, the server replies with a certificate request, so users would select one of the installed PKCS12 certificates and go on like normal.