-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot connect to NextCloud with LetsEncrypt SSL certificate #111
Comments
There is a workaround which can be used, but it is not a final solution and cannot be built in into SilentNotes. You can do it on your own risk, should you encounter problems in other apps, it is possible to reactivate it any time. Navigate to the Android settings: Deactivate this old root certificate: |
Maybe the problem can be overcome by switching the HttpClient to the native Android implementation: https://docs.microsoft.com/en-us/xamarin/android/app-fundamentals/http-stack?tabs=windows , this will be considered for the next version of SilentNotes. A quick test with an ecloud (nextcloud of the /e/ foundation) still gave this error, so switching the option in the Android project doesn't seem to switch the used implementation:
|
Switching to the native Android implementation indeed solves the problem with the SSL certificates, unfortunately the Java implementation of Android does not support the http method "PROPFIND", which is required by WebDav requests. So either we use the default HttpClient implementation (boring-ssl library) which cannot handle the expired SSL certificate, or we use the native Java HttpClient implementation, which cannot send "PROPFIND" requests. The code below shows a possible native Android implementation, which raises the exception:
public class SilentNotes.Android.Startup
{
public static void InitializeApplication(Activity rootActivity, ActivityResultAwaiter rootActivityResultWaiter)
{
...
ICloudStorageClientFactory cloudStorageClientFactory = Ioc.GetOrCreate<ICloudStorageClientFactory>();
cloudStorageClientFactory.RegisterHttpMessageHandlerFactory(() => new Xamarin.Android.Net.AndroidClientHandler());
}
}
public class CloudStorageClientFactory : ICloudStorageClientFactory
{
public void RegisterHttpMessageHandlerFactory(Func<HttpMessageHandler> factory)
{
FlurlHttp.Configure(config => config.HttpClientFactory = new PlatformHttpClientFactory(factory));
}
public class PlatformHttpClientFactory : DefaultHttpClientFactory
{
private readonly Func<HttpMessageHandler> _factory;
public PlatformHttpClientFactory(Func<HttpMessageHandler> factory)
{
_factory = factory;
}
public override HttpMessageHandler CreateMessageHandler()
{
return _factory();
}
}
} See also: skazantsev/WebDavClient#59 . The circumvention with the |
A workaround was built in, but the issue is kept open, for when the development environment allows to solve the issue properly. |
I couldn't connect via SSL to my nextcloud server too. A generic Apache WebDAV server works, only with either of the builtin workaround or the workaround here. I'm stuck because I don't get any meaningful error message, see #174. |
@pkoevesdi - Instead of the workaround it should now be possible to tick the option "Accept unsafe certificates". It depends on your configuration what the url looks like, to get more information you can setup a WebDav connection with Windows Explorer (not Internet Explorer) if you have this OS available. The same credentials should work with SilentNotes too. |
I'm aware of the "Accept unsafe certificates", which was also classified as a workaround here. But as said, on my generic webdav both workarounds work, on my nextcloud none. So, I seem to have a different problem there, sorry for looking for support here, maybe, with the knowledge now, it shows up as the wrong place. I can connect to nextcloud via webdav, which is the url |
On a test account I had to use an url of this form: https://example.com/nextcloud/remote.php/dav/files/USERNAME maybe in your case it could be just http:// . There is no diference, the "Nextcloud WebDav" connection was only added to make it more recognizeable, so a user can find it easier. If the problem persists and you can access the path with other tools, I would be interested in a test account, I would then try to debug the problem. |
Nope, I rewrite http to https on the server.
Ah, ok. But, anyway, thanks for the help and the project! |
Workaround: On Android the default HttpClientHandler uses the underlying Java class "HttpURLConnection", which unfortunately cannot handle the http method "PROPFIND". So when running on Android we make an expection for this single request and use the "SocketsHttpHandler" which has its own implementation, though it cannot validate SSL certificates from LetsEncrypt. We can safely ignore the validation, because consecutive calls will do the validation with the Android implementation. For lower versions of Android (e.g. v7), the "accept unsafe certificates" will still be available, so users can connect to WebDav servers with a certificate which is not yet known to this Android version. |
Finally solved this issue in version 8.0.0, see description above. |
I got the report that SilentNotes on Android devices cannot connect to NextCloud instances anymore, even when they worked before and no settings have changed meanwhile (Windows installations are not affected). After some debugging and research I found out that this is caused by the LetsEncrypt SSL certificate, for an indepth explanation see:
dotnet/android#6351 (comment)
In short:
Since September 29th 2021 the "DST Root CA X3" certificate expired, it was used by LetsEncrypt, so older devices/os/libraries which do not know about LetsEncrypt's own root certificate, can validate the certificate anyway.
Workaround:
A workaround was implemenented, so that NextCloud users can connect to their NextCloud instance, even if the issue can currently not be solved in a satisfying way (scroll down to #111 (comment) for more information). WebDav connections now have a new option to accept invalid certificates, this allows to connect to NextCloud and /e/ cloud services. Unsafe SSL connections are not recommended, but since the content is always end-to-end encrypted anyway, it is justifiable.
The text was updated successfully, but these errors were encountered: