Accept self-signed certificates

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

  • developer

    @dschuermann @brb-at I’m not talking about a cert management app “just for DAVdroid” but for all apps that want to allow self-signed certificates without importing them to the key store.

    My opionion is that (custom) certificate management is a very delicate software part because it’s security-related. Any mistake can render the whole encryption useless, and repeated public code review and testing is needed. So, I don’t like the idea that every app contains its own certificate management, all in different versions and flavours, some never updated and with security-relevant issues that have been fixed in the library’s master tree for a long time. People also won’t review the certificate management code of the apps because they’re interested in the core functionality.

    Also, I don’t consider MemorizingTrustManager in its current version as a “library” because I only see some files that I can merge into DAVdroid. That’s nice and I appreciate the work, but there’s too little task separation for me. I can’t update the trust manager lib just by replacing a .jar file or something like that – that would be the minimum if it’s not a standalone application whose service I can call.

    I’d also like to hear your opinion about these points:

    1. What if the user doesn’t trust the default CAs shipping with Android? I’m quite sure some dubious default CA might issue certificate for the NSA if they get paid for it. So a custom certificate management solution should also provide a way to let the user decide about EVERY certificate, even it is issed by a “trusted” CA. (Disabling every single default CA in the trust store is quite cumbersome.)
    2. Certificate pinning would also be a nice thing because it would allow users to be notified when another certificate is used and to decide if that’s OK. That may be because the user doesn’t trust the installed CAs but may also be relevant in other cases (for instance, if the user’s company has a CA and only a server cert has changed [because for instance, an admin from another department you don’t trust has taken over the DNS]).

    These features could be provided if a cert management app would provide a verification service that can be called not only by DAVdroid but by all apps which need this functionality (Owncloud apps, CalDAV Adapter etc.). This app could have a Settings screen where the user can select whether to trust default CAs.

    Just in case that such a service would make sense, I’d contact the author(s) of MemorizingTrustManager and ask them about their opinion. Maybe they can create the app with the service and DAVdroid and the other apps could call it (if available, else use the default Android handling). In this case, updating the TrustManager would also be sourced out.

    Of course, I’d like to get this thing done with as little work as required – but I fear that this issue just can’t be done with little work.

    Please comment 😉

Log in to reply

Similar topics

  • 20
  • 1
  • 24