ich betreibe eine Nextcloud unter KeyHelp und wollte ONLYOFFICE über eine Subdomain anbinden. Dabei bin ich auf mehrere Probleme gestoßen, insbesondere im Zusammenspiel mit Reverse Proxy, Let's Encrypt und automatisch generierten Apache-Konfigurationen.
Vorab - meine Umgebung:
Server:
KeyHelp Version: 25.3 (Build 3565)
Operating System: Ubuntu 24.04 (64-bit)
Apache Version: Apache 2.4.58
PHP:
System PHP (CLI): PHP 8.3.6
Domain PHP Interpreter: PHP 8.4.17
Nextcloud:
Nextcloud Version: 33.0.0
ONLYOFFICE:
ONLYOFFICE DocumentServer: 8.0
Deployment: Docker
Container Image: onlyoffice/documentserver:8.0
Domainstruktur
domain.de -> Nextcloud
onlyoffice.domain.de -> ONLYOFFICE
Routing:
domain.de -> /home/users/domain/www
Nextcloud Installation -> /home/users/domain/www/nextcloud
onlyoffice.domain.de -> /home/users/domain/www/onlyoffice
Backend Dienst
ONLYOFFICE läuft intern auf:
http://127.0.0.1:8082
Die Subdomain onlyoffice.domain.de sollte als Reverse Proxy auf diesen Dienst zeigen.
Reverse Proxy Konfiguration
Konfiguration über eine KeyHelp custom vHost Datei:
/etc/apache2/keyhelp/custom_vhosts/domain_onlyoffice.domain.de_https.conf
Beispielkonfiguration:
ProxyPreserveHost On
ProxyRequests Off
SSLProxyEngine On
RequestHeader set X-Forwarded-Proto "https"
RequestHeader set X-Forwarded-Ssl on
ProxyPass / http://127.0.0.1:8082/ nocanon
ProxyPassReverse / http://127.0.0.1:8082/
Problem 1 – Let's Encrypt Validierung
Im KeyHelp Log erschien regelmäßig:
Local resolving checks failed for domain "onlyoffice.domain.de"
Please ensure that your domain is locally resolvable!
Der interne Test greift auf folgende URL zu:
http://onlyoffice.domain.de/.well-known/acme-challenge/...
Da die Subdomain vollständig über den Reverse Proxy läuft, wird diese Anfrage an den Backend-Server weitergeleitet.
Erforderlich wäre daher eine Ausnahme wie:
ProxyPass /.well-known !
Problem 2 – KeyHelp überschreibt custom_vhosts
Im Log war zu sehen:
/var/log/keyhelp/cronjob/update.log
Apache: load domain "onlyoffice.domain.de"
Apache: add vhost container for domain "onlyoffice.domain.de"
Dabei wurde folgende Datei regelmäßig überschrieben:
/etc/apache2/keyhelp/custom_vhosts/domain_onlyoffice.domain.de_https.conf
Problem 3 – Apache verwendet weiterhin altes Zertifikat
Ein neues Zertifikat wurde manuell erstellt mit:
certbot certonly --standalone -d onlyoffice.domain.de
Das Zertifikat lag danach unter:
/etc/letsencrypt/live/onlyoffice.domain.de/
Apache lieferte jedoch weiterhin das alte Zertifikat aus, da die Pfade im von KeyHelp generierten vHost gesetzt waren:
/etc/apache2/keyhelp/vhosts/domain.conf
Beispiel:
SSLCertificateFile /etc/ssl/keyhelp/letsencrypt/domain/onlyoffice.domain.de/complete.pem
SSLCertificateChainFile /etc/ssl/keyhelp/letsencrypt/domain/onlyoffice.domain.de/chain.pem
Diese wurden manuell angepasst auf:
SSLCertificateFile /etc/letsencrypt/live/onlyoffice.domain.de/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/onlyoffice.domain.de/privkey.pem
Aktueller Workaround
Proxy-Dateien wurden geschützt:
chattr +i /etc/apache2/keyhelp/custom_vhosts/domain_onlyoffice.domain.de_http.conf
chattr +i /etc/apache2/keyhelp/custom_vhosts/domain_onlyoffice.domain.de_https.conf
Healthcheck:
curl https://onlyoffice.domain.de/healthcheck
true
Frage
Gibt es eine empfohlene Methode innerhalb von KeyHelp, um Reverse‑Proxy‑Subdomains für Dienste wie ONLYOFFICE oder Collabora stabil zu betreiben, ohne dass custom_vhost-Konfigurationen überschrieben werden und ACME-Challenges blockiert werden?
Vielleicht übersehe ich hier auch eine vorgesehene Konfigurationsmöglichkeit in KeyHelp. Falls es eine empfohlene Methode gibt, Reverse‑Proxy‑Subdomains stabil zu betreiben, würde ich mich über einen Hinweis sehr freuen.
Danke und einen guten Start in die Woche
