Support for SSL client certificates
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.
@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?
Which server do you use with client certificate authentication? Could you provide a test account?
@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.
I’m using radicale with Apache 2.4. The setup is very simple with easy-rsa. If you can’t get a package for it, just copy this dir to a temporary location:
Then to setup a throw-away CA and client key:
$ . vars $ ./clean-all $ ./build-ca $ ./build-key email@example.com
Then on the Apache side, the relevant config items are
SSLCACertificateFile /path/to/ca.crt SSLVerifyClient optional SSLUserName SSL_CLIENT_S_DN_SN
And for completeness, if you need the server-side SSL too:
$ . vars $ ./build-key-server server.test.loc
SSLEngine on SSLCertificateFile /path/to/server.test.loc.crt SSLCertificateKeyFile /path/to/server.test.loc.key
Note that the
SSLCACertificateFileCA 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.
@rfc2822 I rearranged some things and can set you up with a test account. Can you contact me privately to set it up?
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):
setuid = stunnel4 setgid = stunnel4 pid = /var/run/stunnel4/stunnel4.pid output = /var/log/stunnel4/stunnel4.log syslog = no debug = 7 cert = /etc/ssl/certs/server.pem CAfile = /etc/ssl/certs/ca.pem CApath = /etc/ssl/trusted/ CRLfile = /etc/ssl/certs/crl.pem verify = 3 session = 14400 TIMEOUTidle = 14400 libwrap = no [caldav] accept = 5232 connect = 172.16.111.111:5232
of course you can extend the configuration for any other relevant services (smtps, imaps).
[imaps] accept = 993 connect = 172.16.111.111:143 [smtps] accept = 587 connect = 172.16.111.111:25
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.
best regards, bf.
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.
Would be glad to help out.
@frank Authentication by client certificates is ready for testing. Are you still interested (after 2 years)?
See also https://forums.bitfire.at/post/9361