I have an app that has not been updated in 6 months - so obviously all of the develop. tools etc. move ahead - and that may be causing this issue… But I cannot find any pointers to solve it.
I have changed my Mac to an M1 version where I run Visual Studio 2019 for Mac. So I had to create new Android emulators (running ARM - blistering fast!). But when my app tries to connect to the sync.gateway I get errors like this:
@blake.meike, I found out that I had to force the use of the native HTTP client that I had configured for the projects to be used when trying to show images. That solved the TLS issues. Is there a similar thing I can do to tell Couchbase Lite to use the “right” HTTP client for the WSS connection?
The TLS certificate is valid (it’s a LetsEncrypt cert.)
This is what I had to do for the image loader:
// Use same http client as set up in project (native handler & TLS1.2+)
FFImageLoading.ImageService.Instance.Initialize(new FFImageLoading.Config.Configuration {
HttpClient = new System.Net.Http.HttpClient()
});
But I haven’t found a way to do something similar for the Replicator in Couchbase Lite…
So the error you are getting is in the certificate chain:
RemoteCertificateChainErrors
I know this sounds strange, but I would check your certificate using SSL Checker and make sure the full chain (path including intermediates) is set up properly :
Check out this post on the LetsEncrypt forums as I think you are experiencing the same problem:
In the past when I had this problem I had load balancing in front of a Sync Gateway cluster and I didn’t install both the root and intermediate certificate on the Ngyix server and that caused issues. It turns out iOS which you think would be more secure doesn’t check the full certificate path - it assumes if the Root is trusted then anything under it is also trusted - at least in my experience.
Yes, I’m sure it is the same issue. I also saw it with the images. The workaround of manually editing the certificate proved it - but obviously wasn’t the solution. However, changing the code to use the native HTTP client works for the images - hence my question about this for the websocket connection. That would be a cleaner solution than having to specify a specific chain cert in the LetsEncrypt certbot. That would just be a “bomb” hitting in 2024…
And as you mention I have an Nginx proxy in front of the website as well as the sync gateway. All looks good in SSLchecker