Accept self-signed certificates

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

  • The actual procedure to add a certificat is too much complicated.

    I tried to access to my owncloud server on a mutualised server for using with mirakel (tasks manager) without success.

    All of us are not developper! 😉

    Please add the option to make it simple and accept the help of dschuermann.

  • developer

    Do you know if MemorizingTrustManager works with sync adapters / whether sync adapters can create a GUI?

  • @rfc2822 Yes, I think it should work. It will show a notification when the certificate can not be validated including a pending intent which results in the dialog provided by memorizingtrustmanager.

  • Hi, the same for me, self-signed certificate .crt, cannot get DAVDROID to work with this certificate “Cannot verify hostname”. The news app for owncloud let me bypass this hostname verification, and i’m very happy with that.
    +1 to warn the user, but let him the freedom to accept or not this unsecure way (in my case, the contacts and calendar are public anyway, so I don’t need a secure solution, I need a Working solution.)
    I just paid for Davdroid, and can’t use it 😞

  • developer

    1. Do you have SNI? 2) If your data is public and you don’t need security for your data (including name/password), why don’t you use HTTP instead of HTTPS? This will save your client’s and server’s resources.

  • @rfc2822, as an aside, https does not cause any noticable performance loss over http. That’s an old issue that is non-existent now

  • developer

    @ainola I strongly advise to use HTTPS wherever possible for privacy reasons, but how shall it work that SSL doesn’t use resources? For every connection, there has to be a key exchange (preferably with PFS) which uses CPU and network resources, while the symmetric block encryption is quite cheap (but not non-existent).

  • @rfc2822 I did not say no resources, I said negligible. will detail the issue.

    This is pretty off-topic though, I apologize for de-railing. Look forward to being able to use this software when I can pin my self-signed certificate. 🙂

  • @rfc2822 There are many well documented political, legal, practical, and generally smart reasons to broadly use encryption. Even if you don’t find any of these compelling, countless numbers of us do.

  • developer

    @dper I don’t get the point. I strongly recommed encryption, you strongly recommend encryption - so?

  • @rfc2822 This is you recommending against it…

    1. If your data is public and you don’t need security for your data (including name/password), why don’t you use HTTP instead of HTTPS? This will save your client’s and server’s resources.

    But perhaps I misread. Sorry. 😕

  • developer

    @dschuermann How does fingerprint checking of MemorizingTrustManager work? I coudn’t find it in the Wiki. I also read that host names and expired certificates are “not supported”, what does that mean? Will it ask for certificates that are valid because they’re in the Android trust store?

  • developer

    At the moment, I think that an independent app that provides a certificate verification service would be the best solution. GUI would go into this app, and it would be separated from DAVdroid.

    DAVdroid could check if this app is present and if it is, the service will be used as a TrustManager. If it is not installed, the default TrustManager will be used and DAVdroid will still work (but without “custom certificate verification”).

    What do you think about this?

  • Fingerprint checking works by knowing the fingerprint from the certificate deployed on your server and then manually comparing it to the one displayed by MemorizinTrustManager. If they are the same it is your certificate and not some man in the middle cert.

    The wiki is really not that helpful. Someone should provide more information…
    “If it encounters an unknown SSL certificate, it asks the user whether to accept the certificate once, permanently or to abort the connection.” (
    This means: If the cert is not known to Android (not in Android’s cert store), MemorizingTrustManager will show the dialog requesting user interaction.
    If that dialog pops up, the validation of the cert is not checked. If the cert is known to Android, the library does not come into action and everything is done as usual by the Android OS (hostname check, validation check etc…)

  • Sry to post another message here. I just read your other comment.
    It will be difficult to code a secure interaction between davdroid and another application that should only be used for verification.
    The library is not big, so why not including it and providing a setting to enable this custom verification code?

  • FYI, Android 4.4 now displays a very obtrusive warning when a self-signed cert is imported into user storage (to warn the user that it could have been installed by a third party to snoop on all SSL connections).

    Implementing an independent cert management app just for DAVDroid is overkill IMHO, when the much simpler solution proposed by dschuermann exists (manual fingerprint verification on first contact). owncloud News Reader, the owncloud app, CalDAV Adapter for Android etc. all use this solution, and it works fine without any security drawbacks.

Log in to reply

Similar topics

  • 1
  • 2
  • 5