Axxel H

It sounds like you have a repro case and don't need screenshots, but to answer the other question this is Android 12 (Pixel 5a). Looking forward to a fix.

Having encountered the crash with this version, I took the usual step of clearing data and attempting to set up the app from scratch. While the fresh install does not crash, it does not allow syncing more than vault via folder (I have not tried other sync styles). I have multiple vaults, one for personal, one for work, etc. Each vault has a separate folder sync location on Android. This has worked with previous builds. In this build I can create a new vault "Personal" with the same vault password that I use for the synced vault on other platforms. I do not store the vault password in the primary vault (this was not required previously). If I configure this vault to sync, it works fine and the empty vault is populated with sync information from the folder as expected. Multiple syncs can occur without issue. Then I add a second vault ("Work") with its own (different) password and set it to sync with a different folder. This also works, populates the new vault with the appropriate information, etc. However, as soon as I add the Work vault sync, the Personal vault sync begins to fail and reports the wrong password. Entering the correct password for that vault does not allow it to sync (reports incorrect password). If I disable sync for Personal, and then reenable it with the correct password, it begins to sync again, but immediately breaks the Work sync in the same way. This pattern repearts for vault 3, 4, etc. At any time only the most recently configured vault for syncing works, all the others reports they have the wrong password, even though they were able to sync before. Its almost like Enpass has forgotten that each synced vault can have its own password.

Also true here. I was brave/foolish enough to reset the app (clear storage) and try to reconfigure it. Unfortunately that's broken in a different way, I'll start a new thread. All in all, a very disappointing release. I've lost mobile access to my passwords till this is fixed.

This remains a problem in Enpass 6.1.0. As soon as I disconnect and reconnect a Mac to a synced folder it breaks the other Macs connected to the same folder. I can ping/pong back and forth, but it never seems to resolve. Some client always reports the error. Any news of a fix?

@Anshu kumar Using Android version 6.0.0.93 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.

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

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.

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?

Correction, the problem with 6.0.0.56 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).

I now see Firefox extension 6.0.0.56 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.

Same problem here, neither the public 5.x Firefox extension nor the beta Enpass 6 extension (6.0.0.6) appear to work with the most recent Enpass Mac beta (6.0.0.250).

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

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 6.0.0.58 continued to sync with the server without error. Can you confirm this is either a bug or expected behavior?

The device is a OnePlus 5 with Oxygen OS 5.1.5 (Android 8.1.0) running Enpass beta 6.0.0.58 (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 6.0.0.220 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?

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?