HTTPS für ONLYOFFICE Docs in Docker konfigurieren

Für eine direkte Verbindung zu ONLYOFFICE Docs veröffentlichen Sie den Container-Port 443, speichern Sie die Zertifikatsdateien im eingebundenen Datenverzeichnis und verweisen Sie den Container auf diese Dateien. Falls bereits ein Reverse-Proxy HTTPS bereitstellt, behalten Sie TLS an diesem Proxy bei und leiten Sie den ursprünglichen Host und das Protokoll an ONLYOFFICE weiter, anstatt standardmäßig einen zweiten TLS-Endpunkt zu aktivieren.

Wenn der öffentliche Hostname beispielsweise lautet docs.example.com, ermitteln Sie zunächst, ob er direkt auf den Dokumentenserver oder auf einen Proxy verweist. Verwenden Sie nur die unten stehende, passende Konfiguration.

1. Entscheiden Sie, wo HTTPS endet

TLS endet dort, wo HTTPS entschlüsselt wird: entweder im ONLYOFFICE-Container oder an einem Reverse-Proxy. Wählen Sie die Komponente aus, die die öffentliche Verbindung empfängt.

• Direkter Zugriff: Clients verbinden sich https://docs.example.comüber den Host-Port 443, der dem Container-Port 443 zugeordnet ist. Der Dokumentenserver-Container benötigt ein Zertifikat und den dazugehörigen privaten Schlüssel.
• Proxy-Zugriff: Clients verbinden sich über HTTPS mit dem Proxy; der Proxy leitet den Datenverkehr über das interne Netzwerk an den Dokumentenserver weiter. In dieser Konfiguration befindet sich das Zertifikat üblicherweise auf dem Proxy. Die Proxy-Richtlinien von ONLYOFFICE erfordern die Header `<script>` X-Forwarded-Protound X-Forwarded-Host`<head>`, damit die Anwendung das öffentliche Anfrageschema und den Hostnamen identifizieren kann.

Portweiterleitung 443:443erzeugt kein HTTPS; sie leitet lediglich Ports weiter. Für den direkten Zugriff muss der Container zusätzlich Zertifikat und Schlüssel lesen können. Wenn der Proxy die öffentliche URL besitzt, verwenden Sie die offizielle Reverse-Proxy-Anleitung von ONLYOFFICE .

2. Konfigurieren Sie HTTPS direkt in Docker Compose.

Verwenden Sie diesen Pfad, wenn der Container HTTPS direkt bereitstellt. Für den öffentlichen Zugriff benötigen Sie ein Zertifikat, dem Clients für den öffentlichen Hostnamen vertrauen. Ein selbstsigniertes Zertifikat kann den Datenverkehr zwar verschlüsseln, Clients warnen jedoch vor Identitätsproblemen, sofern sie nicht separat so konfiguriert sind, dass sie diesem Zertifikat vertrauen.

ONLYOFFICE Docs speichert Zertifikate /var/www/onlyoffice/Data/certsstandardmäßig im unten stehenden Verzeichnis. Die aktuelle Docker-Konfiguration legt die Pfade für Zertifikat und Schlüssel tls.crtals tls.keyStandardpfade fest. Da in den Dokumentationsbeispielen nicht immer identische Dateinamen verwendet wurden, werden in diesem Beispiel beide Pfade explizit angegeben.

services:
  documentserver:
    # Keep your existing image, environment, networks, and other settings.
    ports:
      - "443:443"
    volumes:
      - ./documentserver-data:/var/www/onlyoffice/Data
    environment:
      SSL_CERTIFICATE_PATH: /var/www/onlyoffice/Data/certs/tls.crt
      SSL_KEY_PATH: /var/www/onlyoffice/Data/certs/tls.key

Dies ist ein Auszug, keine vollständige Dienstdefinition. Behalten Sie die bestehenden Einstellungen für Image, JWT, Netzwerk und Volume bei. Platzieren Sie das Zertifikat relativ zur Compose-Datei unter [Pfad] ./documentserver-data/certs/tls.crtund den zugehörigen Schlüssel unter [Pfad] ./documentserver-data/certs/tls.key. Fügen Sie die von Ihrem Anbieter bereitgestellte Zertifikatskette hinzu und stellen Sie sicher, dass das Zertifikat [Pfad] abdeckt docs.example.com.

Die Bind-Mount-Methode hält die Dateien außerhalb eines austauschbaren Containers. Beschränken Sie den Zugriff auf den privaten Schlüssel, stellen Sie aber sicher, dass der Container ihn lesen kann; andernfalls kann HTTPS möglicherweise nicht gestartet werden. Geben Sie den Schlüssel niemals in Supportanfragen weiter.

3. Wenden Sie die Änderung an, ohne die Bereitstellung versehentlich zu ersetzen.

1. Sichern Sie die Compose-Datei und das Zertifikatsverzeichnis und überprüfen Sie anschließend, ob Zertifikat und Schlüssel zum öffentlichen Hostnamen passen.
2. Nehmen Sie die erforderlichen Änderungen an Port, Volume und Pfad im bestehenden Dienst vor. Starten Sie keinen zweiten Container mit demselben Host-Port und verwerfen Sie keine vorhandenen Volumes, um TLS anzuwenden.
3. Erstellen Sie den Dienst neu, wenn Sie dessen Ports, Mounts oder Umgebung geändert haben. Führen Sie dazu bei Verwendung von Compose docker compose up -d documentserverden Befehl im Verzeichnis mit der Compose-Datei aus und ersetzen Sie dabei <Dienstname> durch Ihren tatsächlichen Dienstnamen. Wenn Sie lediglich Zertifikatsdateien in einem bereits eingebundenen Verzeichnis ersetzt haben, starten Sie den vorhandenen Container neu, damit der Server die Dateien neu lädt docker restart <container_name>.
4. Prüfen Sie die Startprotokolle, falls HTTPS nicht funktioniert: docker logs <container_name>Suchen Sie nach Fehlern aufgrund fehlender Dateien, Berechtigungen oder Zertifikate/Schlüssel, bevor Sie andere Einstellungen ändern.

Ein Neustart kann weder eine Einbindung hinzufügen noch veröffentlichte Ports ändern; der Dienst muss für diese Änderungen neu erstellt werden. Das Ersetzen von Dateien in einer bestehenden persistenten Einbindung erfordert keine Änderung in Compose.

4. Behalten Sie TLS auf einem Reverse-Proxy bei, wenn dieser die Domain bereits bedient.

Falls ein Reverse-Proxy bereits beendet ist https://docs.example.com, bewahren Sie dessen privaten Schlüssel auf dem Proxy auf. Leiten Sie den Datenverkehr über ein kontrolliertes Netzwerk weiter und setzen Sie X-Forwarded-Proto: https„plus“ X-Forwarded-Hostauf den öffentlichen Hostnamen. Verwenden Sie das offizielle Beispiel für Ihre Proxy-Software.

Das Schlosssymbol im Browser schützt die Verbindung zwischen Client und Proxy, nicht unbedingt jeden internen Hop. HTTP in einem kontrollierten Docker-Netzwerk mag für manche Bereitstellungen geeignet sein; sichern Sie den Hop vom Proxy zum Container, wenn er ein nicht vertrauenswürdiges Netzwerk durchquert.

Eine weitere Einschränkung: Die Änderung des TLS-Protokolls behebt weder ein ungültiges JWT, noch einen blockierten Firewall-Port oder eine falsche öffentliche Adresse des Dokumentenservers in den Integrationseinstellungen. Wenn das Zertifikat gültig ist, das Laden oder Bearbeiten von Dokumenten aber weiterhin fehlschlägt, überprüfen Sie die entsprechenden Anwendungs- und Proxy-Protokolle, anstatt Zertifikate wiederholt neu zu generieren.

Ergebnis überprüfen

Öffnen und prüfen Sie von einem Client aus, der den öffentlichen Dienst erreichen kann, https://docs.example.comdie Zertifikatsdetails des Browsers. Stellen Sie sicher, dass der Hostname übereinstimmt, das Zertifikat gültig ist und der Browser keinen nicht vertrauenswürdigen Aussteller oder Namenskonflikt meldet. Sie können den TLS-Handshake auch über ein Terminal überprüfen curl -Iv https://docs.example.com; prüfen Sie die Zertifikats- und Verbindungsausgabe, anstatt sich nur darauf zu verlassen, ob eine Seite geladen wird.

Öffnen Sie abschließend ein Dokument aus der integrierenden Anwendung. Die erfolgreiche Browserprüfung bestätigt den öffentlichen Endpunkt, jedoch nicht alle Integrationseinstellungen oder internen Routen. Überprüfen Sie bei Zertifikatswarnungen Hostname, Zertifikatskette, Pfade, Berechtigungen und TLS-Terminierung. Falls die HTTPS-Verifizierung erfolgreich ist, die Bearbeitung aber fehlschlägt, überprüfen Sie Protokolle sowie Authentifizierungs- und Routing-Einstellungen.

Details zu den unterstützten Docker-Pfaden, Zertifikatsvariablen und den integrierten Let's Encrypt-Optionen finden Sie in der Docker-Installations- und HTTPS-Dokumentation von ONLYOFFICE . Der genaue Befehl zum Aktualisieren einer bestehenden Bereitstellung hängt von deren ursprünglicher Erstellung ab. Die aktuellen Volumes und Integrationseinstellungen der Bereitstellung müssen beibehalten werden, während die entsprechenden TLS-Änderungen angewendet werden.