Jump to content

Axxel H

  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Axxel H

  • Rank
  1. Axxel H

    Enpass 6 Android and self-signed CA

    @Anshu kumar Using Android version I'm now getting an error when connecting to Nextcloud that explains the certificate is not trusted, so that's an improvement in the error messages. However, as I indicated the cert is trusted in the user store so I think the problem is the rules around user certificate trust. Again, I'd encourage you to consider allowing self-signed certs with the links I provided above.
  2. Axxel H

    Sync error 815993 after connecting another device

    @Anshu kumar Can we get more information on this issue? At this point my Mac Enpass reports this error code several times a day. Disconnecting/reconnecting sync between every vault when this happens is not a practical long term solution.
  3. Axxel H

    Sync error 815993 after connecting another device

    I should add that the correlation with Android sync appears to be false. I see this error at random now on the Mac even with no changes to the passwords on any device.
  4. I'm using Enpass's folder sync option as a workaround for the problems with self-signed CAs in Android (https://discussion.enpass.io/index.php?/topic/4602-enpass-6-android-and-self-signed-ca/). The contents of the folder are synced across devices using external tools (either Resilio sync or a webdav sync agent). Anytime I connect a new Android device to the sync'ed folder the sync of the Mac client breaks with error 815993. The "Sync Now" button just repeats the error. However, if I disconnect the sync and reconnect the folder on the Mac everything works as expected till I connect another Android device to the same sync folder. Is the Android client touching the sync database in some way that confuses the Mac?
  5. Correction, the problem with appears to be signature verification. "Allow" should bypass the signature check but does not. However, if I disable verification in Enpass app preferences it proceeds to the pairing window. What is odd about this is that this is a standard Firefox 63.0.3 release, no modifications, so no reason for verification to fail (worked with the prior Enpass beta).
  6. I now see Firefox extension on the downloads page (https://www.enpass.io/enpass-beta-downloads/). After installation this version doesn't fail connecting to the Enpass assistant. Instead I see the Enpass popup window with the option to Allow or Reject the connection from Firefox. Clicking the Allow button appears to refresh the window, nothing else occurs. Reject closes the window till I click the toolbar icon again. If I inspect the browser authorizations in the Enpass app preferences Firefox is not listed.
  7. Same problem here, neither the public 5.x Firefox extension nor the beta Enpass 6 extension ( appear to work with the most recent Enpass Mac beta (
  8. Axxel H

    Enpass 6 Android and self-signed CA

    After encountering problems with self-signed certs in a different app, I'm reasonably sure this is the issue: https://android-developers.googleblog.com/2016/07/changes-to-trusted-certificate.html Related discussion here: https://stackoverflow.com/questions/4461360/how-to-install-trusted-ca-certificate-on-android-device https://developer.android.com/training/articles/security-config I'd encourage you to consider adding the exceptions to allow self-signed certs, at least as an option. Other apps I use with NextCloud appear to have done this (CardDAV sync, for example). I'd imagine that other folks running private nextcloud/owncloud/etc. will encounter this issue. While there are security tradeoffs mentioned in the documentation, its not clear there's a better solution for WebDAV sync on Android that doesn't have other concerns (certificate costs, Let's Encrypt 90d expiration, etc.).
  9. Axxel H

    Enpass 6 Android and self-signed CA

    I've conducted a few more experiments, and the results are disappointing: - It appears the problem is not with the intermediate CA, using a cert issued by the root CA fails as well. - It appears the "Bypass SSL certificate verification" option prevents all subsequent SSL verification, offering no man-in-the-middle protection. I was able to introduce a new self-signed cert not issued by any trusted CA and Enpass beta continued to sync with the server without error. Can you confirm this is either a bug or expected behavior?
  10. Axxel H

    Enpass 6 Android and self-signed CA

    The device is a OnePlus 5 with Oxygen OS 5.1.5 (Android 8.1.0) running Enpass beta (the latest available from the Play Store). The certificate chain is as follows: webdav server -> intermediate CA -> root CA (self signed). Both the root and intermediate CAs are installed in the Android security storage for credentials. The Webdav server serves the full cert chain (cert and all CAs). Again, this works fine with the Enpass Mac client. Your response makes me believe this is expected to work, but while you debug can you explain exactly what "Bypass SSL certificate verification" does? There are two interpretations: - It might mean that no verification is performed on initial connection, but subsequent connections must use the same cert. This is safe enough for my purposes, as it is not subject to man-in-the-middle attacks. - It might mean that no certificate verification is performed, and that any certificate can be used and changed at any time, which means man-in-the-middle is a potential issue. Which interpretation does Enpass Android use?
  11. I'm trying to connect the Enpass 6 Android beta to a WebDAV server that has a self-signed certificate issued by a self-signed CA. The CA is installed and trusted in the Android certificate store and works without issue in apps that reference that. This works in Enpass for Mac, but doesn't in Android without enabling "Bypass SSL certificate verification". The release notes for Enpass 5.5.5 indicate that self-signed certs should work, but it doesn't indicate what the expected behavior is. Is needing to enable cert verification expected on Android? Does Enpass at least remember the prior certificate so that man-in-the-middle attacks are not possible?
  12. Sorry, I don't have a server I can offer public access to. It should be easy to set up the config I posted on any Nginx server.
  13. Thank you, it seems that the cause is the Python wrapper "importer_enpass" binary is corrupted? Is it safe to replace this with a copy from the 187 build in the meantime? Or should I import using Enpass 5 and then export a backup file from there? Another issue... When attempting to sync over WebDAV to a Nginx DAV server, Enpass crashes immediately after the PROPFIND request. This is bare Nginx with the DAV extension enabled (not Owncloud/NextCloud) using a config like: location / { dav_methods PUT DELETE MKCOL COPY MOVE; dav_ext_methods PROPFIND OPTIONS; create_full_put_path on; dav_access user:rw; autoindex on; } The site works in the OS X Finder, as well as other WebDAV clients, so I do not believe it's a misconfiguration (and, of course, Enpass shouldn't crash in any case).
  14. On Mac build 220 appears to break most (all?) import options. Importing from 1Password PIF or any of the CSV options (1Password or "Pre-fomatted CSV") returns "Something went wrong, error -9998". I've done the "clear everything" option from advanced, and attempted to import again no change in behavior. Anything else I should try or am I stuck waiting for the next beta? I've been looking forward to trying out folder sync, but if I can't move my data in bulk its not practical to test.