Error while reading 140943FC:SSL

Hey folks, up very late last night trying to resolve some issues syncing up on the Desktop version on Mac OS Catalina - v 2.6.4

Have the error message: Error while reading: error:140943FC:SSL routinges:ssl3_read_bytes:sslv3 alert bad record mac … eed1122

Popping up stopping the sync work. I tried going back a version (2.6.3) but it’s still happening.

The Nextcloud is running on Docker with MariaDB behind a reverse proxy on a Synology NAS. I’ve used an Let’s Encrypt certificate for the HTTPS. I can access it through the web browser fine and it runs through the setup process fine with the desktop client.

I set the desktop proxy to “no proxy”, rather than auto.

Weirdly, when the client starts, I get a message saying it couldn’t connect to the old NAS that was set up before. I’ve not configured the desktop app to do anything with that and am wondering whether there’s something in my MacOS settings that is looking at this.

Here’s the config.

$CONFIG = array (
  'htaccess.RewriteBase' => '/',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'apps_paths' => 
  array (
0 => 
array (
  'path' => '/var/www/html/apps',
  'url' => '/apps',
  'writable' => false,
1 => 
array (
  'path' => '/var/www/html/custom_apps',
  'url' => '/custom_apps',
  'writable' => true,
  'instanceid' => 'ID',
  'passwordsalt' => 'xxx',
  'secret' => 'xxx',
  'trusted_domains' => 
  array (
0 => '',
1 => '',
  'datadirectory' => '/var/www/html/data',
  'dbtype' => 'mysql',
  'version' => '',
  'overwrite.cli.url' => '', 'overwritehost' => '', 'overwriteprotocol' => 'https', 
  'dbname' => 'nextcloud',
  'dbhost' => 'db',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'nextcloud',
  'dbpassword' => 'password',
  'installed' => true,

Still running with this. Desktop app sync log:

[OCC::Folder::slotSyncFinished Client version 2.6.4stable (build 20200303) Qt 5.12.5 SSL OpenSSL 1.1.1d 10 Sep 2019
[OCC::Folder::slotSyncFinished SyncEngine finished with ERROR
[OCC::Folder::showSyncResultPopup Folder sync result: 3
[OCC::Folder::slotSyncFinished the last 2 syncs failed
[OCC::SocketListener::sendMessage Sending SocketAPI message --> “UPDATE_VIEW:/Users/user/example” to SocketApiSocket(0x600002f98d60)
[OCC::ownCloudGui::slotSyncStateChange Sync state changed for folder “” : “Error”
[OCC::AccessManager::createRequest 2 “” “” has X-Request-ID “69feb014-3ee9-424c-9744-ece469141ae8”
[OCC::AbstractNetworkJob::start OCC::JsonApiJob created for “” + “ocs/v1.php/cloud/user” “OCC::UserInfo”
[OCC::FolderMan::slotFolderSyncFinished <========== Sync finished for folder [example] of account [] with remote []
[OCC::FolderMan::startScheduledSyncSoon Starting the next scheduled sync in 17 seconds
[OCC::WebFlowCredentials::slotFinished request finished
[OCC::JsonApiJob::finished JsonApiJob of QUrl(“”) FINISHED WITH STATUS “OK”
[OCC::AccessManager::createRequest 2 “” “” has X-Request-ID “c3f2ad8e-66f6-4cba-b39e-bbd9d74b7151”
[OCC::AbstractNetworkJob::start OCC::AvatarJob created for “” + “” “OCC::UserInfo”
[OCC::WebFlowCredentials::slotFinished request finished
[OCC::AccessManager::createRequest 6 “GET” “” has X-Request-ID “937183c5-7eed-4ca7-af58-acf5c8c47718”
[OCC::AbstractNetworkJob::start OCC::OcsNavigationAppsJob created for “” + “ocs/v2.php/core/navigation/apps” “”
[OCC::WebFlowCredentials::slotFinished request finished

Still running with this problem folks, I’d appreciate any help. This is the error log on the nginx reverse proxy host:

2020/06/24 14:35:16 [error] 17203#17203: *648290 connect() failed (111: Connection refused) while connecting to upstream, client: 162.158.154.x, server: {nextcloudURL}, request: “GET /ocs/v2.php/core/navigation/apps?absolute=true&format=json HTTP/1.1”, upstream: “”, host: " {nextcloudURL}"

Trying to figure out what that IP address is there - that 162… - that’s not my IP address. That’s Cloudflare IP - could it be I need to enter a regex for the Cloudflare IPs in the trusted_proxy config.php?

Not sure if the domain problem is a red herring or not. Switched DNS servers over to see if it still comes up as an error or not.

Still getting this problem. Wondering why I’m getting an ssl3 error message when sslv3 is depreciated. Is that the protocol NC uses to communicate with the host? Looks like it’s disabled on mine, and I’ve tried enabling it but that doesn’t seem to be working.

I’d really appreciate a bit of help here, been at this a few days now and my head is hurting!

Here’s the Synology RP settings.

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name {NC_URL};

    client_max_body_size 0;
    underscores_in_headers on;

    ssl_certificate /usr/syno/etc/certificate/ReverseProxy/xx/fullchain.pem;

    ssl_certificate_key /usr/syno/etc/certificate/ReverseProxy/xx/privkey.pem;

    add_header Strict-Transport-Security "max-age=15768000; includeSubdomains; preload" always;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2 SSLv3;

    location / {

        proxy_connect_timeout 12000;

        proxy_read_timeout 12000;

        proxy_send_timeout 12000;

        proxy_intercept_errors off;

        proxy_http_version 1.1;

        proxy_set_header        Host            $host;

        proxy_set_header        X-Real-IP            $remote_addr;

        proxy_set_header        X-Forwarded-For            $proxy_add_x_forwarded_for;

        proxy_set_header        X-Forwarded-Proto            $scheme;

        proxy_set_header        Front-End-Https            on;


        proxy_headers_hash_max_size 512;
        proxy_headers_hash_bucket_size 64;

        proxy_buffering off;
        proxy_redirect off;
        proxy_max_temp_file_size 0;


    error_page 403 404 500 502 503 504 @error_page;

    location @error_page {
        root /usr/syno/share/nginx;
        rewrite (.*) /error.html break;
        allow all;


As you can see - I’ve tried enabling SSLv3 there (as well as the Nginx config on the NAS), to no avail.

same for me now.

Solved. Changing access point, it works. Probably there is something wrong with some cached ssl certificate or similar issue with one access point.

yes the problem is with connection on router side, look this