Thanks for the suggestion! Can you provide a list of available tags + reference?
As many self hosted servers don’t have CA-signed certificates, I propose to include the MemorizingTrustManager library.
It provides a dialog for trusting self-signed certificates after manual fingerprint checking.
I already implemented it for ownCloud News Reader, hopefully this helps to understand how to integrate the library: https://github.com/dschuermann/News-Android-App/commit/47d8fd2dad0807e826d12b71253e454cffa97223
If you need help don’t hesitate to ask me.
Thanks for your idea. However, I prefer to import the self-signed certificates to the certificate storage because it doesn’t require any additional treatment on app side. Please see http://davdroid.bitfire.at/configuration for details, I have written a section about this.
you are trying to force people to setup a whole CA just for ssl securing their private server stuff. thats absolute overkill. no one sets up a CA just for this. if people are using self signed certs, than they simply create a public private key pair, and not setting up a CA. that user who opened this thread offered to help you to implement a support for this pub/priv keys, but too bad you dont want his help. I found this because my carddav is not working because of this reason described here, so I have to search for another software now, and thats a pain in the azz …
You can install self signed certs the same way as you install custom CAs.
Well,there are also StartSSL and CAcert where you can get a signed certificate for free.
@kaimi nope, I tryed it with CM10.1. That function is intended to import CA certs. It installs the pub cert sucessfully, but it dont appears in the cert store, and is not available to apps wich would make sense if its just for CA certs. but maybe this is a bug in CM, I dont know…
@viq yes sure! but since that NSA leak for me and many other ppl CA companys are compromised and dead of trust now. Selfsigned certs are the last and best way remaining to use pki… 2ct
Off course, you are under no obligation to spend time on features you don’t need. But I would like to ask you to reconsider taking up the original submitter’s offer for help.
There are three reasons I would like to submit:
Say, I run a server with a self-signed certificate and would like family members to set up their phones to sync with accounts on that server. Importing a certificate is something that they will not be able to do without my help (and that they might even consider too much a hassle with my help), whereas choosing “accept” once on a dialogue is acceptable for them. It’s not a small difference, in their eyes it’s the difference between “no problem” and “these open source apps are so complicated, a normal person cannot use them”.
A lot of other apps use the “display dialogue on first contact” approach to self-signed certificates, so many users will be familiar with that (e.g. OwnCloud file sync, Gibberbot etc.)
Even as a fairly technically inclined person, I would have to need to search for a tutorial in order to find out how to get a .pem file for the certificate of some else’s server. As sharing access to private servers (that often have self-signed certificates) is one of the major use cases for this app (think calendar sharing in the family or the office), a solution which can be applied by the average user without need to consult handbooks or web sites would be very useful.
Thank you for your great work!
@unsacred666 no, self-signed certs are not a solution, a self-created CA is. Yes, it is more hassle, but there’s software that makes it easier, and it is WAYS more secure than self-signed, not to mention that if you protect multiple services you only have one cert to add.
@viq I don’t know of any difference between a self-signed cert and a self-created CA that signes certs. In both ways your cert is not pre-deployed on the device.
Also both have the same disadvantage, that even when you use one of them, a compromised trusted CA can issue a new certificate for your domain playing MitM. MitM attacks can only be prevented by pinning your self-signed cert or self-created CA. See http://nelenkov.blogspot.de/2012/12/certificate-pinning-in-android-42.html for more information about pinning in Android 4.2
@dschuermann I’d have to find it again, saw some security person talking about CA giving you much greater control than a simple self-signed cert.
I would like to use my own self-sign certs as well, so please find a solution how people can use there own certs and are not depending on third partys.
https://github.com/moxie0/AndroidPinning could be a solution
@rfc2822 AndroidPinning would need a user interface to add pinned certs/pub keys. Currently it is only useful to hardcode a pinned cert/pub key.
@rfc2822 Same problem to me, I transferred my Owncloud server 5.0.12. During the transfer I also tried self signed certificates for testing. After that davdroid is not accepting my startssl certificate any more, all the other apps and also the software of my debian system is still working fine… Anyway, thanks for the cool FOSS app!
@hubgitti @rfc2822 Sorry, I had a typo in the SSL config of the webserver for CA and chain file. The other applications just didn’t bother…
I have to point out that merely setting up davdroid to use my self-signed cert requires me to alter the fundamental way in which I use Android.
If CM had working encryption, I’d be using passworded devices, but as it stands PINs/Passwords are useless. Yet in order to import my certificate I must set one up. I understand that this is Android’s fault for including bizarrely specific security settings when there are a million more UI holes but it is rather silly to not accept certs on the app level.
Thanks for a great program, though. I look forward to using it someday.
It is relevant that both StartSSL and CACert offer free keys, but they only offer free keys that expire after, what, six months or a year? No user wants to have to go screw around on the command line and generate a new certificate file to copy to their phone to import to their security settings every six months.
Lack of simple self-signed SSL support is a show stopper. This is definitely a deciding issue for me, and I’m sure there are many others who feel the same.
Also, a question. With Apache, when we’re self-signing, we get a
crt. Can that be imported directly?
With Apache, when we’re self-signing, we get a crt. Can that be imported directly?
+1 for an implementation of certificate pinning.
I definitely agree that importing your own CA into Android would be the ideal solution, that is in fact what I’ve done for myself, but that just isn’t feasible for the average user.
First of all, going through the procedure of importing the certificate is not something that I can explain to my average family member; so I’ll have to do it for them.
This isn’t your fault but an Android implementation clusterfuck, but I can’t explain to them that because of “this new calendar thingy” they suddenly can’t use their pattern unlock anymore but have to use a pincode instead.
Also an implementation clusterfuck, as if Google is receiving a fat pile of money from the large certificate authorities to make it as unattractive as possible to import custom ones, importing a custom CA causes a “An unknown party is capable of monitoring your internet connection” warning to be displayed at startup and added to the notification area permanently. Can’t explain that one either.
These things make davdroid unsuitable for anyone but power users, while I’d love to be able to recommend it to all of my friends and family.
And, as someone has said earlier, depending on your paranoia level a certificate pinning system might be even more secure than importing your CA: if you do the latter, any of Android’s 100 trusted CA’s that you’ve never even heard of can still generate a valid certificate for your domain which would probably go completely unnoticed; while pinning would alert you about it/prevent it.