can't connect to push server: cURL error 35: error 141A10F4

[cindrmon]

Hello..

I just want to ask why do I have this error?

root@server # occ notify_push:setup https://cloud.my-domain.moe/push
✓ redis is configured
🗴 can't connect to push server: cURL error 35: error:141A10F4:SSL routines:ossl_statem_client_read_transition:unexpected message (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://cloud.my-domain.moe/push/test/cooki

I have everything all configured properly from the setup instructions; the nginx config, the systemctl service, and i didn't even touch the nextcloud config.php..

I've been looking everywhere, but I feel lost on what in particular am I supposed to look for this particular error.

I also had a similar issue when I tried connecting my local Collabora online CODE server to my own nextcloud instance on the same server, and this was the exact error it gave.

the https://cloud.my-domain.moe/push/test/cookie works fine, but this error is always getting in the way when I type the command occ notify_push:setup https://cloud.my-domain.moe/push.

System Versions: OS: Debian GNU/Linux 10 Kernel: Linux 4.19.0-17-amd64 Nginx: 1.14.2 MariaDB: 10.3.29 Redis: 5.0.3 PHP: 7.3.29 Nextcloud: 22.1.0

Config Files For Reference: nginx.conf/sites-available/nextcloud

upstream php-handler {
    #server 127.0.0.1:9000;
    server unix:/var/run/php/php7.3-fpm.sock;
}

server {
    listen 80;
    listen [::]:80;
    server_name cloud.my-domain.moe;

    # Enforce HTTPS
    return 301 https://$server_name$request_uri;
}

server {
    listen 443      ssl http2;
    listen [::]:443 ssl http2;
    server_name cloud.my-domain.moe;

    ssl_certificate /etc/letsencrypt/live/cloud.my-domain.moe/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/cloud.my-domain.moe/privkey.pem;

    # HSTS settings
    # WARNING: Only add the preload option once you read about
    # the consequences in https://hstspreload.org/. This option
    # will add the domain to a hardcoded list that is shipped
    # in all major browsers and getting removed from this list
    # could take several months.
    add_header Strict-Transport-Security "max-age=15552000; includeSubDomains; preload;";

    # set max upload size
    client_max_body_size 512M;
    fastcgi_buffers 64 4K;

    # Enable gzip but do not remove ETag headers
    gzip on;
    gzip_vary on;
    gzip_comp_level 4;
    gzip_min_length 256;
    gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
    gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;

    # Pagespeed is not supported by Nextcloud, so if your server is built
    # with the `ngx_pagespeed` module, uncomment this line to disable it.
    #pagespeed off;

    # HTTP response headers borrowed from Nextcloud `.htaccess`
    add_header Referrer-Policy                      "no-referrer"   always;
    add_header X-Content-Type-Options               "nosniff"       always;
    add_header X-Download-Options                   "noopen"        always;
    add_header X-Frame-Options                      "SAMEORIGIN"    always;
    add_header X-Permitted-Cross-Domain-Policies    "none"          always;
    add_header X-Robots-Tag                         "none"          always;
    add_header X-XSS-Protection                     "1; mode=block" always;

    # Remove X-Powered-By, which is an information leak
    fastcgi_hide_header X-Powered-By;

    # Path to the root of your installation
    root /var/www/nextcloud;

    # Specify how to handle directories -- specifying `/index.php$request_uri`
    # here as the fallback means that Nginx always exhibits the desired behaviour
    # when a client requests a path that corresponds to a directory that exists
    # on the server. In particular, if that directory contains an index.php file,
    # that file is correctly served; if it doesn't, then the request is passed to
    # the front-end controller. This consistent behaviour means that we don't need
    # to specify custom rules for certain paths (e.g. images and other assets,
    # `/updater`, `/ocm-provider`, `/ocs-provider`), and thus
    # `try_files $uri $uri/ /index.php$request_uri`
    # always provides the desired behaviour.
    index index.php index.html /index.php$request_uri;

    # Rule borrowed from `.htaccess` to handle Microsoft DAV clients
    location = / {
        if ( $http_user_agent ~ ^DavClnt ) {
            return 302 /remote.php/webdav/$is_args$args;
        }
    }

+    # Backend Service (for Notify Push)
+    location ^~ /push/ {
+       proxy_pass http://127.0.0.1:7867/;
+       proxy_http_version 1.1;
+       proxy_set_header Upgrade $http_upgrade;
+       proxy_set_header Connection "Upgrade";
+       proxy_set_header Host $host;
+        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+    }

    location = /robots.txt {
        allow all;
        log_not_found off;
        access_log off;
    }

    # Make a regex exception for `/.well-known` so that clients can still
    # access it despite the existence of the regex rule
    # `location ~ /(\.|autotest|...)` which would otherwise handle requests
    # for `/.well-known`.
    location ^~ /.well-known {
        # The rules in this block are an adaptation of the rules
        # in `.htaccess` that concern `/.well-known`.

        location = /.well-known/carddav { return 301 /remote.php/dav/; }
        location = /.well-known/caldav  { return 301 /remote.php/dav/; }

        location /.well-known/acme-challenge    { try_files $uri $uri/ =404; }
        location /.well-known/pki-validation    { try_files $uri $uri/ =404; }

        # Let Nextcloud's API for `/.well-known` URIs handle all other
        # requests by passing them to the front-end controller.
        return 301 /index.php$request_uri;
    }

    # Rules borrowed from `.htaccess` to hide certain paths from clients
    location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/)  { return 404; }
    location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console)                { return 404; }

    # Ensure this block, which passes PHP files to the PHP process, is above the blocks
    # which handle static assets (as seen below). If this block is not declared first,
    # then Nginx will encounter an infinite rewriting loop when it prepends `/index.php`
    # to the URI, resulting in a HTTP 500 error response.
    location ~ \.php(?:$|/) {
        fastcgi_split_path_info ^(.+?\.php)(/.*)$;
        set $path_info $fastcgi_path_info;

        try_files $fastcgi_script_name =404;

        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $path_info;
        fastcgi_param HTTPS on;

        fastcgi_param modHeadersAvailable true;         # Avoid sending the security headers twice
        fastcgi_param front_controller_active true;     # Enable pretty urls
        fastcgi_pass php-handler;

        fastcgi_intercept_errors on;
        fastcgi_request_buffering off;
    }

    location ~ \.(?:css|js|svg|gif)$ {
        try_files $uri /index.php$request_uri;
        expires 6M;         # Cache-Control policy borrowed from `.htaccess`
        access_log off;     # Optional: Don't log access to assets
    }

    location ~ \.woff2?$ {
        try_files $uri /index.php$request_uri;
        expires 7d;         # Cache-Control policy borrowed from `.htaccess`
        access_log off;     # Optional: Don't log access to assets
    }

    # Rule borrowed from `.htaccess`
    location /remote {
        return 301 /remote.php$request_uri;
    }

    location / {
        try_files $uri $uri/ /index.php$request_uri;
    }

}

nextcloud/config/config.php

<?php
$CONFIG = array (
  'instanceid' => '<instance_id>',
  'passwordsalt' => '<salt>',
  'secret' => '<secret>',
  'trusted_domains' => 
  array (
    0 => 'cloud.my-domain.moe',
  ),
  'datadirectory' => '/mnt/data/webappData/Nextcloud/data',
  'dbtype' => 'mysql',
  'version' => '22.1.0.1',
  'overwrite.cli.url' => 'https://cloud.my-domain.moe',
  'dbname' => '<db_name>',
  'dbhost' => '<db_host>',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => '<db_username>',
  'dbpassword' => '<db_password>',
  'installed' => true,
  'maintenance' => false,
  'htaccess.RewriteBase' => '/',
  'default_phone_region' => '<phone_region>',
  'memcache.distributed' => '\\OC\\Memcache\\Redis',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'memcache.local' => '\\OC\\Memcache\\Redis',
  'filelocking.enabled' => 'true',
  'redis' => 
  array (
    'host' => '/var/run/redis/redis-server.sock',
    'port' => '0',
    'timeout' => 0.0,
    'dbindex' => 0,
    'password' => '<redis_password>',
  ),
  'app_install_overwrite' => 
  array (
    0 => 'groupfolders',
  ),
  'trusted_proxies' => 
  array (
    0 => '127.0.0.1',
    1 => '::1',
    2 => '<local_ip>',
    3 => '<public_ip>',
  ),
);

system/notify_push.service

[Unit]
Description = Push daemon for Nextcloud clients
Documentation=https://github.com/nextcloud/notify_push

[Service]
Environment = PORT=<default_port>
ExecStart = /var/www/nextcloud/apps/notify_push/bin/x86_64/notify_push /var/www/nextcloud/config/config.php
User=www-data

[Install]
WantedBy = multi-user.target

[CheariX]

I'm having the same issue. Did you find a solution?

[cindrmon]

I haven't yet. But for some reason, from my other issue where I can't establish a connection from within the same server when I'm trying to set up loolwsd, it works when I use an external instance (separate from the nextcloud server) of loolwsd.

[CheariX]

OK. I finally found my solution.

Can you try to run:

1. curl "https://cloud.my-domain.moe/push/test/cookie"
2. docker-compose exec --user www-data app curl "https://cloud.my-domain.moe/push/test/cookie" // adjust app name

Do you get a cookie in both cases? In my case, the URL was reachable from everywhere but the nextcloud-docker-app itself (because of my traefik setup).

[joshtrichards]

Closing per:

• https://github.com/nextcloud/notify_push/issues/123#issuecomment-958378227
• No further traffic on this issue for 2+ years