Von Zeit zu Zeit erscheinen nun neue Versionen des Docker-Containers von ONLYOFFICE. Um hier ein Update durchzuführen, sind nur wenige Schritte erforderlich.
Zunächst muss die ID des laufenden Containers mit folgendem Befehl ermittelt werden:
docker ps
Der Container wird gestoppt und entfernt:
docker stop <Container-ID> docker rm <Container-ID>
Die neue Version des Containers wird über diesen Befehl herunter geladen:
docker pull onlyoffice/documentserver
falls die folgenden Verzeichnisse nicht existieren, müssen sie angelegt werden ("Volumes" des Containers, um Dateien persistent auf dem Host zu speichern / nach einer Neu-Generierung des Docker-Containers stehen die dort gespeicherten "alten" Dateien wieder zur Verfügung/ s.u.):
mkdir -p /app/onlyoffice/DocumentServer/logs mkdir -p /app/onlyoffice/DocumentServer/data mkdir -p /app/onlyoffice/DocumentServer/lib mkdir -p /app/onlyoffice/DocumentServer/db mkdir -p /app/onlyoffice/DocumentServer/etc/hosts mkdir -p /app/onlyoffice/DocumentServer/data/certs
falls die Datei "hosts" nicht in "/app/onlyoffice/DocumentServer/etc/" existiert, aus Docker-Container kopieren und mit der Zeile "172.16.189.16 ja-service.lkmsh.de" ergänzen (IP-Nummer des host, unter der der Docker-Container den Host-Server erreichen kann, id.R. 172.17.0.1, und server-name )
docker cp ONLYOFFICEDOCKER:/etc/hosts /app/onlyoffice/DocumentServer/etc/hosts nano /app/onlyoffice/DocumentServer/etc/hosts
172.16.189.16 ja-service.lkmsh.de
Nun kann der aktualisierte Container wie gewohnt gestartet werden:
docker run --name=ONLYOFFICEDOCKER -i -t -d -p 8443:443 --restart=always \
-e JWT_ENABLED='true' -e JWT_SECRET='97jfbeil05' \
-v /app/onlyoffice/DocumentServer/logs:/var/log/onlyoffice \
-v /app/onlyoffice/DocumentServer/data:/var/www/onlyoffice/Data \
-v /app/onlyoffice/DocumentServer/lib:/var/lib/onlyoffice \
-v /app/onlyoffice/DocumentServer/db:/var/lib/postgresql \
-v /app/onlyoffice/DocumentServer/etc/hosts:/etc/hosts \
onlyoffice/documentserver
Folgende Punkte gilt es hier zu beachten:
Bevor nun die Verbindung zu ONLYOFFICE in Nextcloud hinterlegt werden kann, muss noch eine kleine Anpassung an der Konfiguration von Nextcloud erfolgen. Dazu wird die Konfiguration mit folgendem Befehl auf der Konsole geöffnet:
nano /var/www/nextcloud/config/config.php
Hier wird nun am Ende der Datei (aber vor der letzten schließenden Klammer) ein Eintrag hinzugefügt:
'onlyoffice' =>
array (
'verify_peer_off' => true,
),
Dieser Schritt ist zwingend erforderlich, da Nextcloud sonst die Verbindung zu ONLYOFFICE auf Grund des selbst signierten Zertifikats nicht zulässt.
Am Schluss sollte der ganze Rechner einmal neu gestartet werden:
reboot now
Der letzte Schritt zu einer Online-Office-Lösung mit Nextcloud ist nun nur noch das Hinterlegen der Verbindungs-Details zwischen der Cloud und ONLYOFFICE.
Dazu in Nextcloud einfach in die Einstellungen gehen. Unter Verwaltung > ONLYOFFICE findet man nun die entsprechenden Einstellungen:
Nach einem Klick auf Speichern sollte eine Erfolgsmeldung kommen und die Verbindung zwischen Nextcloud und ONLYOFFICE wurde erfolgreich konfiguriert.
Validierung des Zertifikats durch ONLYOFFICE DokumentServer auschalten, wie folgt:
Docker-Container betreten
docker exec -t -i ONLYOFFICEDOCKER bash
Folgende Konfigurations-Datei aufrufen und bearbeiten
nano /etc/onlyoffice/documentserver/default.json
Einstellung "services.CoAuthoring.requestDefaults.rejectUnauthorized" von "true" auf "false" setzen
services.CoAuthoring.requestDefaults.rejectUnauthorized=false
DokumentServer Services neustarten:
supervisorctl restart all
Docker-Container verlassen
exit
CA-Rootzertifikat als anerkannte Zertifizierungsstelle dem DokumentServer bekannt machen:
CA-Rootzertifikat in den Container des DokumentServer kopieren:
docker cp /etc/nginx/ssl/ca-root-ja-service.pem ONLYOFFICEDOCKER:/etc/ssl/certs/ca-root-ja-service.pem
Docker-Container betreten
docker exec -t -i ONLYOFFICEDOCKER bash
CA-Rootzertifikat dem System-CA bekannt machen:
mkdir /usr/local/share/ca-certificates/extra cp /etc/ssl/certs/ca-root-ja-service.pem /usr/local/share/ca-certificates/extra/root.cert.crt update-ca-certificates
Docker-Container verlassen
exit
NODEjs - Einstellungen anpassen / CA-Rootzertifikat bekannt machen (ab Version 8 ? / aktuell: 6.1)
CA-Rootzertifikat in den Container des DokumentServer kopieren:
docker cp /etc/nginx/ssl/ca-root-ja-service.pem ONLYOFFICEDOCKER:/etc/ssl/certs/ca-root-ja-service.pem
Docker-Container betreten
docker exec -t -i ONLYOFFICEDOCKER bash
Konfigurations-Datei von NODEjs aufrufen:
nano /etc/onlyoffice/documentserver/supervisor/onlyoffice-documentserver-converter.conf
und Umgebungsvariable "NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-root-ja-service.pem" hinzufügen
NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-root-ja-service.pem
DokumentServer Services neustarten:
supervisorctl restart all
Docker-Container verlassen
exit
OpenSSL bringt umfassende Werkzeuge mit, um eine eigene, kleine Certificate Authority (CA) betreiben zu können. Die Nutzung einer eigenen CA ist besonders dann sinnvoll, wenn mehrere Dienste über SSL/TLS kostenlos abgesichert werden sollen. Neben dem Nachteil, dass die eigene CA vor Benutzung zuerst auf den Clientrechnern bekannt gemacht werden muss, gibt es aber auch einen Vorteil: Mit einer CA unter der eigenen Kontrolle ist man im Zweifel auf der sicheren Seite: In den letzten Jahren wurden immer wieder Fälle bekannt, in denen große Certificate Authorities falsche Zertifikate ausgestellt haben. Es gibt Grund genug, die Vertrauenswürdigkeit großer CAs anzuzweifeln.
Mit dieser Anleitung werdet ihr in der Lage sein, beliebig viele Zertifikate für eure Dienste ausstellen zu können, die in jedem Browser als gültig erkannt werden, sofern vorher das Root-Zertifikat eurer CA importiert wurde.
cd /home/tjeckel/ca
Zu Beginn wird die Certificate Authority generiert. Dazu wird ein geheimer Private Key erzeugt:
openssl genrsa -aes256 -out ca-key.pem 2048
Der Key trägt den Namen „ca-key.pem“ und hat eine Länge von 2048 Bit. Wer es besonders sicher haben will, kann auch eine Schlüssellänge von 4096 Bit angeben. Die Option „-aes256“ führt dazu, dass der Key mit einem Passwort geschützt wird. Die Key-Datei der CA muss besonders gut geschützt werden. Ein Angreifer, der den Key in die Hände bekommt, kann beliebig gefälsche Zertifikate ausstellen, denen die Clients trauen. Die Verschlüsselung dieses Keys mit einem Passwort gibt zusätzlichen Schutz. Das gewünschte Passwort wird bei der Generierung abgefragt.
Einen geheimen Key für die CA gibt es nun also schon – fehlt noch das CA-Root-Zertifikat, das von den Clients später importiert werden muss, damit die von der CA ausgestellten Zertifikate im Browser als gültig erkannt werden. Das CA-Root-Zertifikat „ca-root.pem“ wird mit folgendem Befehl erzeugt: (ggf. wird das Passwort für den vorher erstellen Key abgefragt!)
openssl req -x509 -new -nodes -extensions v3_ca -key ca-key.pem -days 3650 -out ca-root.pem -sha512
In diesem Fall wird die CA 3650 Tage (= 10 Jahre) lang gültig bleiben. Während der Generierung werden das Passwort für die CA und einige Attribute abgefragt (hier ein Beispiel):
Country Name (2 letter code) [AU]: DE State or Province Name (full name) [Some-State]: Sachsen-Anhalt Locality Name (eg, city)[]: Lutherstadt Eisleben Organization Name (eg, company) [Internet Widgits Pty Ltd]: Kreisverwaltung MSH Organizational Unit Name (eg, section) []: Jugendamt Common Name (eg, YOUR name) []: ja-service.lkmsh.de Email Address []: thorsten.jeckel.lkmsh.de
Damit ein Rechner die selbst ausgestellten Zertifikate akzeptiert, muss auf diesem Rechner das Root-Zertifikat (Public Key der CA) importiert worden sein. Die Root-CA-Datei ist „ca-root.pem“.
Mozilla Firefox verwaltet Zertifikate selbst. Ein neues Zertifikat wird importiert unter „Einstellungen ⇒ Erweitert ⇒ Zertifikate ⇒ Zertifikate anzeigen ⇒Zertifizierungsstellen ⇒ Importieren“. Wählt die Datei „ca-root.pem“ aus. „Wählt die Option „Dieser CA vertrauen, um Websites zu identifizieren“.
„Einstellungen“ ⇒ „Erweiterte Einstellungen anzeigen“ (unten) ⇒ „HTTPS/SSL“ ⇒ „Zertifikate verwalten“ ⇒ „Zertifizierungsstellen“ ⇒ „Importieren“ ⇒ „ca-root-pem“ auswählen ⇒ „Diesem Zertifikat zur Identifizierung von Websites vertrauen“
sudo mkdir /usr/local/share/ca-certificates/extra sudo cp /etc/ssl/certs/ca-root-ja-service.pem /usr/local/share/ca-certificates/extra/root.cert.crt sudo update-ca-certificates
⇒ Neue Zertifikate akzeptieren
Die CA ist nun fertig und kann genutzt werden. Zeit, das erste Zertifikat auszustellen! Grundlage ist immer ein privater Schlüssel. Wie auch bei der CA wird dieser Private Key erzeugt:
openssl genrsa -out zertifikat-key.pem 4096
An dieser Stelle ein Passwort zu setzen ist in den meisten Fällen nicht besonders sinnvoll. Ein Webserver, der des Zertifikat verarbeitet, müsste bei jedem Start das Passwort abfragen. Das ist in der Praxis mehr lästig und hinderlich als nützlich. (⇒ Passwortfelder einfach leer lassen). Die Schlüssellänge wurde hier auf paranoide 4096 Bit gesetzt. 2048 sind auch okay ;)
Nun wird eine Zertifikatsanfrage erstellt, bei der wieder einige Attribute abgefragt werden. Besonderheit ist hier: Das Feld „Common Name“ muss den Hostnamen des Servers tragen, für den es gültig sein soll. Soll z.B. die Verbindung zum Rechner mit der IP-Adresse „192.168.2.2“ mit dem Zertifikat abgesichert werden, muss die IP-Adresse hier angegeben werden. Soll das Zertifikat dagegen für die Domain thomas-leister.de gelten, muss das ebenso eingetragen werden. Es ist auch möglich, sog. Wildcard-Zertifikate zu erstellen. Wird z.B. „*.thomas-leister.de“ als Common Name angegeben, gilt das Zertifikat für alle Domains von thomas-leister.de, also login.thomas-leister.de, start.thomas-leister.de usw. – nicht aber für thomas-leister.de selbst. Das Challenge Passwort wird nicht gesetzt (leer lassen).
openssl req -new -key zertifikat-key.pem -out zertifikat.csr -sha512
Sobald die Zertifikatsanfrage „zertifikat.csr“ fertiggestellt ist, kann sie von der CA verarbeitet werden. Dabei entsteht der öffentliche Schlüssel (Public Key) zum angefragten Zertifikat. Dieser wird zusammen mit dem Private Key des Zertifikats für die Verschlüsselung benötigt.
Mit folgendem Befehl wird ein Public Key „zertifikat-pub.pem“ausgestellt, der 3650 Tage (=10 Jahre) lang gültig ist:
openssl x509 -req -in zertifikat.csr -CA ca-root.pem -CAkey ca-key.pem -CAcreateserial -out zertifikat-pub.pem -days 3650 -sha512
(Das Passwort für die CA wird erneut abgefragt.) Die Zertifizierungsanfrage zertifikat.csr kann gelöscht werden – sie wird nicht mehr benötigt. Übrig bleiben und Public Key des neuen Zertifikats (zertifikat-key.pem und zertifikat-pub.pem) sowie Private- und Public Key der CA (ca-key.pem und ca-root.pem).
Die Zertifikat-Dateien findet man anschließend im Verzeichnis /home/tjeckel/ca:
| ca-key.pem | Private-Key der ROOT-CA / Key-Chain / | wird zur Generierung von Zertifikaten benötigt |
| ca-root.pem | Public-Key der ROOT-CA / intermediate SSL certificate | wird von verbundenen Geräten benötigt |
| zertifikat-key.pem | Private-Key Zertifikat Server | wird vom webserver benötigt |
| zertifikat-pub.pem | Public-Key Zertifikat Server / end-user certificate | wird vom webserver benötigt |
| zertifikat-pub.pem + ca-root.pem | Root-Chain / Full-Chain / fullchain.pem | cat ca-root.pem » zertifikat-pub.pem |
In der Webserver-Konfiguration müssen üblicherweise drei Zertifikatsdateien angegeben werden:
Der Public Key der CA kann auch an die Public Key Datei des Zertifikats angehängt werden:
cat ca-root.pem >> zertifikat-pub.pem
Diese Integration ist immer dann nötig, wenn es keinen Parameter in der Konfiguration gibt, bei dem man das Rootzertifikat einer CA angeben kann – beim XMPP Server Prosody und beim Webserver Nginx ist das z.B. der Fall: Hier können nur Public- und Private Key des Zertifikats angegeben werden.
Falls notwendig werden die Zertifikate noch umbenannt, z.B.:
mv zertifikat-key.pem certificate-archiv-werkzeuge.key mv zertifikat-pub.pem certificate-archiv-werkzeuge.crt mv ca-root.pem ca-root-archiv-werkzeuge.pem
Und in das "ssl"-Verzeichnis des NGINX-Servers kopiert:
cp /home/tjeckel/ca/certificate-archiv-werkzeuge.key /etc/nginx/ssl/certificate-archiv-werkzeuge.key cp /home/tjeckel/ca/certificate-archiv-werkzeuge.crt /etc/nginx/ssl/certificate-archiv-werkzeuge.crt cp /home/tjeckel/ca/ca-root-archiv-werkzeuge.pem /etc/nginx/ssl/ca-root-archiv-werkzeuge.pem
Für den Docker-Container "ONLYOFFICEDOCKER" sind die Dateien in folgendes Verzeichnis mit neuem Namen zu kopieren:
cp /home/tjeckel/ca/certificate-archiv-werkzeuge.key /app/onlyoffice/DocumentServer/data/certs/onlyoffice.key cp /home/tjeckel/ca/certificate-archiv-werkzeuge.crt /app/onlyoffice/DocumentServer/data/certs/onlyoffice.crt cp /home/tjeckel/ca/ca-root-archiv-werkzeuge.pem /app/onlyoffice/DocumentServer/data/certs/ca-root-archiv-werkzeuge.pem
Das soeben erzeugte SSL-Zertifikat ist der wichtigste Schritt, damit später sämtliche Verbindungen zur eigenen Cloud verschlüsselt ablaufen. Die Sicherheit dabei kann aber durch den Einsatz sog. Diffie-Hellman-Parameter weiter erhöht werden. Das Thema ist etwas komplexer, aber einfach ausgedrückt geht es hierbei um einen sicheren Schlüsselaustausch bei Verbindungsaufbau. Die Generierung der Parameter ist recht einfach.
Achtung: Auf schwächerer Hardware kann die Generierung hier einige Stunden dauern. Wer nicht so lange warten möchte, der kann auch einen Schlüssel mit „nur“ 2048 Bit errechnen lassen (die Zahl des zweiten Befehls gibt hierbei die Länge des Schlüssels in Bit an).
cd /etc/nginx/ssl openssl dhparam -out /etc/nginx/ssl/dhparams.pem 4096
Die Zertifikat-Dateien sind natürlich schützenswert, daher sollten die Dateiberechtigungen angepasst werden, so dass nur noch der Besitzer der Dateien Lese- bzw. Schreibrechte hat:
chmod 600 /etc/nginx/ssl/dhparams.pem chmod 600 /etc/nginx/ssl/certificate-archiv-werkzeuge.key chmod 600 /etc/nginx/ssl/certificate-archiv-werkzeuge.crt chmod 600 /etc/nginx/ssl/ca-root-archiv-werkzeuge.pem
# Certificates used ssl_certificate /etc/nginx/ssl/certificate-archiv-werkzeuge.key; ssl_certificate_key /etc/nginx/ssl/certificate-archiv-werkzeuge.key; # Not using TLSv1 will break: # Android <= 4.4.40 # IE <= 10 # IE mobile <=10 # Removing TLSv1.1 breaks nothing else! # TLSv1.3 is not supported by most clients, but it should be enabled. ssl_protocols TLSv1.2 TLSv1.3; # Cipher suite from https://cipherli.st/ # Max. security, but lower compatibility ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384'; # Cipher suite from https://wiki.mozilla.org/Security/Server_Side_TLS #ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'; # (Modern) cipher suite from https://mozilla.github.io/server-side-tls/ssl-config-generator/ #ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'; # Diffie-Hellman parameter for DHE ciphersuites, recommended 4096 bits ssl_dhparam /etc/nginx/ssl/dhparams.pem; # Use multiple curves. # secp521r1: Not supported by Chrome # secp384r1: Not supported by Android (DAVdroid) ssl_ecdh_curve secp521r1:secp384r1:prime256v1; # Server should determine the ciphers, not the client ssl_prefer_server_ciphers on; # OCSP Stapling # fetch OCSP records from URL in ssl_certificate and cache them ssl_stapling on; ssl_stapling_verify on; # This should be chain.pem # See here: https://certbot.eff.org/docs/using.html ssl_trusted_certificate /etc/nginx/ssl/ca-root-archiv-werkzeuge.pem; resolver 192.168.178.1; # SSL session handling ssl_session_timeout 24h; ssl_session_cache shared:SSL:50m; ssl_session_tickets off;