Nextcloud ist nicht mehr über https erreichbar

[Obeldobel]

Nextcloud Hub 10 (31.0.4), Debian Bookworm, Apache2, MariaDB.

Nach Versuche “Whiteboard” und Reverseproxy einzurichten ist meine Webseite nicht mehr über https zu erreichen. Kann sein, das auch dieser Versuch nicht damit zu tun hat:

Ich habe 2 Webserver hinter der Fritzbox laufen: https://obeldobel.+++++++++++++.com und https://+++++++++++8123 (Domain zwecks Fehlereingrenzung gelöscht). Nun habe ich verschiedene Tests laufen lassen (u.A SSL Labs) und der Test sagte dann, wenn ich https://obeldobel.chickenkiller.com angebe, dann wird das Zertifikat von obeldobel.duckdns.org angezeigt.

Hat jemand einen Tipp?

Schönes Osterfest euch

Edit: Kann keine sichere Verbindung zu obeldobel.chickenkiller.com herstellen:

Der Name des Hosts ist keiner aus der Liste der für dieses Zertifikat gültigen Hosts

mit Zertifikat obeldobel.+++++++++.org

Fritzbox 7950, Raspberrypi 3,

nextcloud-le-ssl.conf

ServerAdmin admin@example.com DocumentRoot /var/www/html/nextcloud/ ServerName obeldobel.+++++++++++.com

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains; strict-origin; preload"
  Redirect 301 /.well-known/carddav /nextcloud/remote.php/dav
  Redirect 301 /.well-known/caldav /nextcloud/remote.php/dav
</IfModule>

 Alias /nextcloud "/var/www/html/nextcloud/"

       
 <Directory /var/www/html/nextcloud/>
    Options +FollowSymlinks
    AllowOverride All
    Require all granted
      <IfModule mod_dav.c>
        Dav off
      </IfModule>
    SetEnv HOME /var/www/html/nextcloud
    SetEnv HTTP_HOME /var/www/html/nextcloud
 </Directory>

SSLProxyEngine on
SSLProxyProtocol +all
SSLProxyCipherSuite ALL
SSLProxyCheckPeerName off
SSLProxyCheckPeerCN off
SSLProxyCheckPeerExpire off

  

 ErrorLog ${APACHE_LOG_DIR}/error.log
 CustomLog ${APACHE_LOG_DIR}/access.log combined

SSLCertificateFile /etc/letsencrypt/live/obeldobel.chickenkiller.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/obeldobel.chickenkiller.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf

options-ssl-apache.conf

This file contains important security parameters. If you modify this file

manually, Certbot will be unable to automatically provide future security

updates. Instead, Certbot will print and log an error message with a path to

the up-to-date file that you will need to refer to when manually updating

this file.

SSLEngine on

Intermediate configuration, tweak to your needs

SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
SSLHonorCipherOrder on
SSLCompression off

SSLOptions +StrictRequire

Add vhost name to log entries:

LogFormat “%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-agent}i"” vhost_combined
LogFormat “%v %h %l %u %t "%r" %>s %b” vhost_common

#CustomLog /var/log/apache2/access.log vhost_combined
#LogLevel warn
ErrorLog /var/log/apache2/error.log

Always ensure Cookies have “Secure” set (JAH 2012/1)

#Header edit Set-Cookie (?i)^(.)(;\ssecure)??((\s*;)?(.*)) “$1; Secure$3$4”

[leachimus]

Ohne genaue Angabe über dein System und Konfiguration läuft hier nix mit Hilfestellung.

[mwildam]

Das verwendete Zertifikat muß zu der Domain passen, die entsprechend über DNS mit der richtigen IP vom entsprechenden Apache-Server benutzt wird - hast Du evtl die beiden verwechselt?

[Obeldobel]

Das wird das Problem sein: beide Webserver haben die gleiche IP, weil sie beide hinter der Fritzbox hängen. Das System lief ja auch fehlerfrei über 2 Jahre. Nur: wie bekomme ich das wieder hin, dass das richtige Zertifikat meiner Domain obeldobel.chickenkiller.com zugewiesen wird?

[leachimus]

Ich komme aktuell auf die Login Maske. Schein, als in du das Problem lösen konntest?

[TheWojtek]

You didn’t set the reverse proxy properly. You have a single Apache2 configuration that creates a Nextcloud server and has some proxy statements, but what does it proxy? Itself? This is not how a reverse proxy works.

You need to create a vanilla, non-ssl Apache2 config for Nextcloud, running http on a port of your choosing, NOT 80, NOT 443. This is your backend server.

Then you need to create a proxy config for another http server, this time:

• running on 80 & 443
• configured to upgrade your http connection to https
• with all your certificates attached
• configured with proxy statements to actually proxy your connections from the outside to your Nextcloud http server, so it will be your fronted http(s) server.

The Nextcloud config can be extremely basic. Do not set no SSL there, do not put any header statements there. It’s proxy’s job to do that.

The proxy config should:

• upgrade any connection from 80 to 443 ssl
• handle the certificates
• handle the headers.

IMHO it’s way too much fuss with Apache to use it as a reverse proxy and I always use Nginx on the frontend to do the proxying on a separate host (it handles 10 domains in my case, not all of them are using Nextcloud), however my actual servers run Apache2 because I am lazy. So the backend Nextcloud host running Apache2 has a very simple config:

<VirtualHost *:8000>
  DocumentRoot /var/www/nextcloud/
  ServerName  FQDN-of-my-nextcloud-instance
  ErrorLog ${APACHE_LOG_DIR}/nextcloud_error.log
 CustomLog ${APACHE_LOG_DIR}/nextcloud_access.log combined
  <Directory /var/www/nextcloud/>
    Require all granted
    AllowOverride All
    Options FollowSymLinks MultiViews
    <IfModule mod_dav.c>
      Dav off
    </IfModule>
 </Directory>
    <FilesMatch \.php$>
      SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost"
    </FilesMatch>
</VirtualHost>

Now the proxy (frontend) server: it runs on a different machine, could be on the same but then proxying wouldn’t make a lot of sense anyway. Remember, this is not Apache2 but Nginx:

# redirect this...
server {
    listen 80;
    server_name FQDN-of-my-nextcloud-instance;
    access_log /var/log/nginx/cloud_access.log;
    error_log /var/log/nginx/cloud_error.log;
    location / {
    return 301 https://FQDN-of-my-nextcloud-instance$request_uri;
    }
}

This part above catches any http connection to 80 and sends it to be upgraded to SSL.

# ...to this
server {
    listen 443 ssl;
    server_name FQDN-of-my-nextcloud-instance;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    access_log /var/log/nginx/cloud_access.log;
    error_log /var/log/nginx/cloud_error.log;
   ssl_certificate           /etc/letsencrypt/live/FQDN-of-my-nextcloud-instance/fullchain.pem;
   ssl_certificate_key       /etc/letsencrypt/live/FQDN-of-my-nextcloud-instance/privkey.pem;
   ssl_session_cache  builtin:1000  shared:SSL:10m;
   ssl_protocols  TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
   ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
   ssl_prefer_server_ciphers on;

The above part handles SSL upgrade and headers. Now for what should the proxy actually do - what to listen for and what to serve:

location / {
  proxy_pass http://192.168.192.208:8000;

This is the internal IP of my Nextcloud http server.

  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";
  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 X-Forwarded-Host $host;
  proxy_set_header X-Forwarded-Port $server_port;
  proxy_set_header client-ip $remote_addr;
  # Fix the “It appears that your reverse proxy set up is broken" error.
  proxy_cache_key $scheme://$host$uri$is_args$query_string;
  proxy_cache_valid 200 10m;
  proxy_read_timeout  90;
  proxy_redirect      http://192.168.192.208:8000 https://FQDN-of-my-nextcloud-instance;
}

Here is the actual statement: get the data from the backend server and present it to the world on the frontend identified by FQDN.

location /.well-known/carddav {
    return 301 $scheme://$host/remote.php/dav;
}

location /.well-known/caldav {
    return 301 $scheme://$host/remote.php/dav;
 }
}

Since you want to have no “caldav” errors in your NC administration screen.

I simplified my example because I handle my http3/quic traffic using additional config snippet so don’t even have the certificates in this config file, but this would work as well.

If your instance runs OK on http and you don’t want to bother with creating a working Apache2 proxy or learning how to set up a proxy in Nginx manually, just use a docker of Nginx Proxy Manager, configure it using GUI and you’re all set.

[Obeldobel]

Leider nein.

Bist via https oder http drauf gekommen? http geht auch bei mir

[leachimus]

Ja, war doch http. Aber arbeite die Hilfestellung erst mal durch. Das ist ziemlich genau das, was evtl. dein Problem ist.

Ich hab dir auch eine private Nachricht geschickt. Bitte dringend beachten!

[Obeldobel]

Danke für die Tipps. Leider hat keiner geholfen.

Ich habe das System neu aufgesetzt.

[leachimus]

Nimm die Möglichkeit der Registrierung noch raus.