"Blocked Page" error message (nginx config)

hermann-san

Hi everybody,
I've installed and configured Cryptpad and I have some difficulties to get is running. I can get to the Cryptpad page, but when I try to create a new document, I get an error message. It says

Blocked Page
An error occurred during a connection to cryptpad (Sandbox domain).

Cryptpad is installed with NGINX behind an external reverse Proxy. I suppose that I have to configure something in the nginx config file, but I'm not sure what exactly. I guess in the location section - proxy_set_header. Does someone has an idea what I could try? I've attached my config. I've tried native install (preferred) and Docker, but it's both the same.
Thanks in advance.


config/config.js   (Docker and non-Docker)
 httpUnsafeOrigin: 'https://cryptpad.domain',
 httpSafeOrigin: 'https://cryptpad-sand.domain',
 httpAddress: '10.10.x.x',


server {
     listen 80;
     listen [::]:80;
     access_log /dev/null;
     error_log /dev/null emerg;
     
cryptpad-test [hostname] cryptpad.domain cryptpad-sand.domain;

    httpSafeOrigin: "https://cryptpad.domain";
    httpUnsafeOrigin: "https://cryptpad-sand.domain";
    httpAddress: '10.10.x.x'
        

resolver 8.8.8.8 8.8.4.4 1.1.1.1 1.0.0.1 9.9.9.9 149.112.112.112 208.67.222.222 208.67.220.220;

# I've not touched the location section

    location / {
        proxy_pass            http://localhost:3000;
        proxy_set_header      X-Real-IP $remote_addr;
        proxy_set_header      Host $host;
        proxy_set_header      X-Forwarded-For $proxy_add_x_forwarded_for;
        client_max_body_size  150m;

        proxy_http_version    1.1;
        proxy_set_header      Upgrade $http_upgrade;
        proxy_set_header      Connection upgrade;
    }

    location ^~ /cryptpad_websocket {
        proxy_pass            http://localhost:3003;
        proxy_set_header      X-Real-IP $remote_addr;
        proxy_set_header      Host $host;
        proxy_set_header      X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_http_version    1.1;
        proxy_set_header      Upgrade $http_upgrade;
        proxy_set_header      Connection upgrade;
    }
}




Docker:
version: '3.8'

services:
  cryptpad:
    image: "cryptpad/cryptpad:version-2024.6.1"
    hostname: cryptpad

    environment:
      - CPAD_MAIN_DOMAIN=https://cryptpad.domain
      - CPAD_SANDBOX_DOMAIN=https://cryptpad-sand.domain
      - CPAD_CONF=/cryptpad/config/config.js

    volumes:
      - ./data/blob:/cryptpad/blob
      - ./data/block:/cryptpad/block
      - ./customize:/cryptpad/customize
      - ./data/data:/cryptpad/data
      - ./data/files:/cryptpad/datastore

    ports:
      - "3000:3000"
      - "3001:3001"
      - "3003:3003"

    ulimits:
      nofile:
        soft: 1000000
        hard: 1000000

config.js is the same, docker and non-docker (see above)  httpSafeOrigin, httpSafeOrigin, httpAddress

Image description

AlexQ

Hello @hermann-san , what happened? According to your past post I thought you have CryptPad successfully up and running via docker.

Let's try to get the native install running:

a) So this is a coplete new install?
b) Recent version 2024.9.0?
c) On Debian/Ubuntu I suppose?

e) Since you specifically asked for the nginx config, where did you get yours from?
f) Did you truncate some of the posted nginx conf? I'm missing the server_name directive.
g) Did you setup TLS/https? I'mmissing all the ssl directives.

Please consider that nginx usally has several conf files which get summed up. So there may be other active configurations within your setup.

For a basic check please do the following:

1) check your nginx conf with the shell command nginx -t
2) use the CryptPad check: https://cryptpad.domain/checkup/
3) check CryptPad logs: /home/{cryptpaduser}/cryptpad/data/logs/

Good luck, please give feedback.

hermann-san

Hello @AlexQ Thanks for your answer. It's been a while since I worked with that installation, but as far as I remember I've got that issue with the Docker installation after upgrading from Version 5.7 to version 6.0. Back then I started afterwards from scratch with the native installation since I've heard that SSO is not available for Cryptpad docker install .

a) yes, it's a new install but upgraded from 6.0 to 9.0
b) yes, 2024.9.0
c) Debian 12
e) nginx config is the standard example config suggested in the installation guide (on github)
f) actually I thought that the actuall server name is to be replaced for server_name. But apparently I was wrong. So that the first thing that's not right and I've correct it, but after restarting nginx and cryptpad, there is not change in regard to the blocked page.
g) since my Cryptpad server is in a trusted environment behind a reverse proxy, I removed all of the SSL config (as I also do with other apps). Am I required to change to SSL config (or is it recommended anyways?) The SSL certificate resides on the reverse proxy, but I could also copy the certificate on the cryptpad server, but I would prefer to let the reverse proxy renew the certificate.

Actually I don't really need nginx. I only configured it out of desperation because it didn't work even without nginx. I thought I have more options with nginx in regards to the reverse proxy config.

1) nginx -t is OK, test successful
2) The checkup had the following 5 issue's and they all seem to be related to a reverse proxy issue.

Your browser was not able to load an iframe using the origin specified as httpSafeOrigin (https://cryptpad-sand.domain) in cryptpad/config/config.js. This can be caused by an invalid httpUnsafeDomain, invalid CSP configuration in your reverse proxy, invalid SSL certificates, and many other factors. More information about your particular error may be found in your browser console. Changes to cryptpad/config/config.js will require a server restart in order for /api/config to be updated.

/sheet/inner.html does not have the required 'content-security-policy' headers set. This is most often related to incorrectly configured sandbox domains or reverse proxies.

/common/onlyoffice/dist/v7/web-apps/apps/spreadsheeteditor/main/index.html does not have the required 'content-security-policy' headers set. This is most often related to incorrectly configured sandbox domains or reverse proxies.

api/config returned an HTTP status code other than 200 when accessed from the sandbox domain.

https://cryptpad.domain.org/sheet/inner.html was served with incorrect Content-Security-Policy headers.

A value of "'none'" was expected for the default-src directive.

A value of "'unsafe-inline' 'self' https://cryptpad.domain" was expected for the style-src directive.

A value of "'self' data: https://cryptpad.domain" was expected for the font-src directive.

A value of "https://cryptpad.domain" was expected for the child-src directive.

A value of "'self' blob: https://cryptpad-sand.domain" was expected for the frame-src directive.

A value of "'self' resource: https://cryptpad.domain 'unsafe-eval' 'unsafe-inline'" was expected for the script-src directive.

A value of "'self' blob: https://cryptpad.domain  https://cryptpad-sand.domain  wss://cryptpad.domain" was expected for the connect-src directive. This rule restricts which URLs can be loaded by scripts. Overly permissive settings can allow users to be tracked using external resources, while overly restrictive settings may block pages from loading entirely.

A value of "'self' data: blob: https://cryptpad.domain" was expected for the img-src directive.

A value of "blob:" was expected for the media-src directive.

A value of "'self' https://cryptpad.domain" was expected for the frame-ancestors directive. This rule determines which sites can embed content from this instance in an iframe.

A value of "'self'" was expected for the worker-src directive.

AlexQ

@hermann-san The quickest way to fix this, is to stay close to recommendations.

So yes, please use nginx as reverse proxy and the SSL certificate needs to be assigned to the actual domains, which are reachable via internet. The CryptPad checkup fails mainly because of wrong SSL config. It's much easier to geht help and to debug if you follow the recommendations.

a) I'm confused, new but upgrade? 😃 So did you isntall 2024.6.0 and then upgraded to 2024.9.0?
b) ok
c) ok
e) ok, but you need to repair and use all the dircetives of the example, here seems to be the root cause
f) please post your complete nginx conf and simply replace / censor all your domain names before posting, you can use e.g. example.com, cryptpad.example.com and sandbox.example.com

1) ok, good, didn't expect that ;-)
2) yes, I agree not working SSL nginx / config

New question: Which tool do you use for SSL, letsencrypt I suppose: acme.sh? certbot?

All in all I think when we fix your nginx.conf most or all of your problems will be gone. Please use the whole example config, adjust it where needed, check your sSL and post your censored ngxing conf and the current state of your problem as next step.

AlexQ

@hermann-san Addendum:

Be prepared for a failing nginx conf when you add the SSL. Depending on how oyu do it you may end up with duplicate dicrectives in your CryptPad nginx config and your default nginx conf.

As written, use nginx -t to check if the config is valid and then sovle the issues, when the config fails. Usally you have to delete duplicate directives, so they don't exist in both nginx config files since they are getting combined.

Use a search engine for reported issues, sometimes the nginx version differs, so not all statements are supported and you need to use the old directives.

I'm curious for your feedback and hope we'll get your instance running 🙂

hermann-san

ok, found out what it was. 🥳
The problem was all on the reverse proxy,
I had 2 domains in my main cryptpad certificate (as mentioned in the nginx cryppad config file) but I had a second reverse proxy backend for the sandbox domain and I also had a second certificate for the sandbox domain. This second certificate and backend is not needed.
So I only need 2 conditions (main domain and sandbox domain) and 2 rules (main domain and sandbox domain) .
I also only need one certificate, one "real server" and only one backend.

There a no more error with the cryptpad checkup (except a few warnings)

Thanks a lot again for pointing me in the right direction 👍️

AlexQ

@hermann-san Ah, great, and faster than expected.

Remember as last actions to:

use CryptPad checkup page
check CryptPad logs (ignore / delete the old logs, note the time stamps)
use nginx -t one last time
restart CryptPad service / reboot server
(consider to install the minor CryptPad update published today)

hermann-san

nginx -t is still ok and server reboot is also ok.

I do have HAProxy on an external server as my external reverse proxy. NGINX is the "internal" reverse proxy on the cryptpad server itself.
Have I understood you right that you recommend to also put the SSL certs on the cryptpad server itself?
I understand that the http communcation is unencrypted, but is this also the case for cryptpad the case? So there is no additional encryption underneath the http traffic, right? If so, I'm sure I must put the certificate on the cryptpad server as well, so that there is no encryption gap in the client server communication.

AlexQ

@hermann-san

AFAIK it should be:

client <--SSL--> Internet <--SSL--> CryptPad via reverse proxy <--http/internal--> NodeJS CryptPad server internal

Sorry if I was misleading, english is not my native language. I think we're talkign about the same 🙂

AlexQ

@hermann-san I think you're doing it right. The SSL certs are for encrypting the public itnernet traffic, not the internal traffic within the server. My hint was prior to understanding your setup where I wondered. If the CryptPad checkup no longer states errors then your SSL setup should be fine.

If everything runs and you woudl like to close the topic then please do:

mark one of your or mine postings as solutions, so that the whole topic is marked as solved via green check mark
adjust you're topic title, so that others can better find this thread, e.g. "blocked page" error message in browser [solved]

hermann-san

same for me, non-native....
I've just added my external HAProxy to the picture, but I think I've got it. Even though I have a save private network, I should still configure it with https instead of http.
Thanks again.

https = SSL
Image description

AlexQ

@hermann-san Exactly, looks right for me. The additonal HA proxy was unusal to me compared to the most setups user describe. So now it's clear.