Nextcloud und die unsichtbare Last der Zertifikate

Nextcloud und die unsichtbare Last der Zertifikate

Man muss sich das einmal klar machen: Eine Nextcloud-Instanz ist im Grunde nichts weiter als ein ambitioniertes PHP-Projekt, das sich als Dateisynchronisation, Gruppenware und mittlerweile fast als Betriebssystem für die eigene Cloud tarnt. Doch so charmant die Open-Source-Altlasten auch sein mögen – an der Verschlüsselung führt kein Weg vorbei. Und genau hier beginnt das Thema, das Administratoren immer wieder in die Irre führt: die Zertifikatsverwaltung. Kein glamouröses Feature, zugegeben. Aber ohne funktionierende SSL/TLS-Zertifikate ist die schönste Nextcloud nur ein teures HTML-Exponat im Browser.

Dabei zeigt sich ein eigentümlicher Widerspruch. Nextcloud selbst hat über die Jahre eine beachtliche Reife erreicht. Die Entwickler haben vieles vereinfacht: Ein-Klick-Updates, App-Ökosystem, Office-Integration. Aber bei der Einrichtung von sicheren Verbindungen bleiben viele Anwender auf halber Strecke stehen. Nicht weil es schwer wäre – es ist trivial, irgendein Zertifikat draufzupacken. Sondern weil die Verwaltung, Erneuerung und der gesamte Lebenszyklus eines Zertifikats im Alltag oft stiefmütterlich behandelt werden. Dabei ist genau das der Punkt, an dem Sicherheit und Betriebsstabilität kippen können.

Warum ein selbstsigniertes Zertifikat keine Lösung ist

Ja, für eine Testumgebung reicht es. Oder wenn man der einzige Benutzer ist und die Browser-Warnung einfach wegklickt. Aber sobald mehrere Geräte, Mobile Clients oder externe Partner ins Spiel kommen, wird das selbstsignierte Zertifikat zum Flaschenhals. Die Nextcloud-Desktop-Clients meckern, die Kalender-App unter iOS wirft Fehler, und Outlook klemmt beim CardDAV-Sync. Die Fehlermeldungen sind dann meist kryptisch: „Verbindung fehlgeschlagen“ oder „Zertifikatsfehler“. In Wirklichkeit ist es immer dasselbe – das Betriebssystem oder der Client vertraut der ausgestellten Bescheinigung nicht, weil sie nicht von einer anerkannten Stelle signiert wurde.

Das ist nicht wirklich neu, aber überraschenderweise wird dieses Problem in vielen Nextcloud-Foren immer wieder neu aufgeworfen. Administratoren versuchen dann, ihre eigenen Zertifizierungsstellen (Certificate Authorities, CA) aufzubauen oder importieren mühsam per Skript Zertifikate in den Systemtruststore. Das kann funktionieren, aber es erzeugt einen erheblichen Wartungsaufwand. Und wer hat schon Lust, alle drei Monate ein neues Root-CA-Zertifikat auf die Geräte aller Mitarbeiter zu verteilen? Genau das passiert nämlich irgendwann, wenn die selbstbetriebene CA keine automatische Verlängerung durch den ACME-Standard (Automatic Certificate Management Environment) unterstützt. Und dann ist das Geschrei groß.

Ein interessanter Aspekt ist, dass Nextcloud selbst – ich spreche hier von der aktuellen Version 28 oder 29 – keine eigene Zertifikatsverwaltung im engeren Sinne anbietet. Es gibt keine Web-Oberfläche, um ein Zertifikat hochzuladen oder einen ACME-Client zu konfigurieren. Das ist nicht unbedingt ein Manko, denn die Verantwortung für den TLS-Stack liegt traditionell beim Webserver, also Apache oder Nginx. Nextcloud kümmert sich um die Applikation, nicht um die Transportschicht. Aber genau diese Arbeitsteilung wird oft vergessen. Man installiert Nextcloud, richtet die Datenbank ein, konfiguriert den Speicher – und wundert sich dann, dass der Zugriff per HTTPS nicht klappt, weil der Webserver kein gültiges Zertifikat hat.

Let’s Encrypt – der Retter in der Not, aber nicht blindlings

Die Erfindung von Let’s Encrypt war für die gesamte Branche ein Segen. Plötzlich war es möglich, in wenigen Minuten kostenlose, von einer global anerkannten CA signierte Zertifikate zu erhalten. Nahezu jeder Nextcloud-Einrichtungsguide empfiehlt den Einsatz von Certbot oder acme.sh. Und das ist auch richtig so. Aber die Fallstricke liegen im Detail.

Ein häufiges Problem: Die automatische Verlängerung. Wer seinen Webserver nicht korrekt konfiguriert hat, bei dem schlägt die Erneuerung des Zertifikats fehl, weil der ACME-Client die Domain nicht über Port 80 oder 443 erreichen kann – oder weil die Firewall den Zugriff auf das ACME-Verzeichnis blockiert. Dann bleibt das Zertifikat abgelaufen, und die nächsten Clients verbinden sich nicht mehr. Das ist besonders ärgerlich, wenn man die Nextcloud nur von außen erreicht, aber der ACME-Client lokal auf einem internen Rechner läuft. Oder wenn man hinter einem Reverse-Proxy arbeitet, der die ACME-Challenge nicht korrekt weiterleitet.

Ich habe schon Konstellationen gesehen, in denen ein Nginx-Reverse-Proxy vorgeschaltet war, die ACME-Challenge aber nur auf dem internen Apache landete. Das Zertifikat wurde dann zwar ausgestellt, aber nicht für die öffentliche Domain – Chaos war programmiert. Manche Administratoren greifen dann zu Notlösungen wie dem manuellen Kopieren der Zertifikatsdateien per SCP, was auf Dauer unhaltbar ist.

Nicht zuletzt spielt die Frage der Domain eine Rolle. Nextcloud wird oft auf Subdomains wie cloud.beispiel.de betrieben. Das ist kein Problem für Let’s Encrypt, solange die Domain öffentlich im DNS eingetragen ist. Aber was ist mit internen Nextcloud-Instanzen, die nur im Firmennetz laufen? Für solche Fälle gibt es mittlerweile ACME-fähige DNS-Provider, die eine automatische Validierung per DNS-Eintrag erlauben. Oder man baut sich eine eigene CA mit einem ACME-Server – etwa mit Step-CA oder dem kleinen ACME-Client von Smallstep. Das ist zwar aufwendiger, aber für Unternehmen mit vielen internen Diensten eine saubere Lösung.

Die Nextcloud-App „External Sites“ und das Zertifikats-Missverständnis

Ein Thema, das oft unterschätzt wird: Die Zertifikatsverwaltung betrifft nicht nur die Nextcloud-Instanz selbst, sondern auch die darin eingebundenen externen Dienste. Die App „External Sites“ erlaubt es, Webseiten oder Anwendungen in einem IFrame anzuzeigen. Wenn diese externen Seiten aber kein gültiges Zertifikat haben, schlägt die Anzeige fehl – oder der Browser warnt. Das führt dann zu Verwirrung bei den Anwendern, die denken, die Nextcloud sei kaputt.

Ähnlich verhält es sich mit benutzerdefinierten Links auf Kalender- oder Kontaktressourcen. Werden diese von einem anderen Server bereitgestellt, der kein vertrauenswürdiges Zertifikat besitzt, scheitert die Synchronisation. Der Administrator sucht dann den Fehler in der Nextcloud-Konfiguration, obwohl er eigentlich auf dem Zielserver liegt. Daher mein Rat: Führen Sie eine zentrale Zertifikatsstrategie für alle Cloud-ähnlichen Dienste ein, nicht nur für Nextcloud.

Eigene Zertifikate in Nextcloud einspielen – wie geht das?

Nehmen wir an, Sie haben bereits ein Zertifikat von einer anderen CA, etwa von einer kommerziellen Stelle, oder Sie nutzen eine interne PKI. Dann müssen Sie dieses Zertifikat dem Webserver zur Verfügung stellen – und nur diesem. Nextcloud selbst hat keine Schnittstelle, um Zertifikate hochzuladen. Das ist gut so, denn es trennt die Zuständigkeiten.

Die typische Vorgehensweise unter Linux: Sie legen die Dateien (Zertifikat, privater Schlüssel, ggf. CA-Kette) in /etc/ssl/certs und /etc/ssl/private ab, passen die Rechte an und referenzieren sie in der Webserver-Konfiguration. Bei Apache also in der VirtualHost-Datei:

SSLEngine on
SSLCertificateFile /etc/ssl/certs/nextcloud.crt
SSLCertificateKeyFile /etc/ssl/private/nextcloud.key
SSLCertificateChainFile /etc/ssl/certs/ca-chain.crt

Bei Nginx ist es ähnlich, nur mit den Direktiven ssl_certificate und ssl_certificate_key. Wichtig: Der private Schlüssel muss absolut geschützt sein – also chmod 600 und idealerweise im Besitz von root. Manche Betriebe machen den Fehler, die Dateien weltweit lesbar zu machen, nur weil das Zertifikat sonst nicht gelesen wird. Das ist ein gravierendes Sicherheitsrisiko.

Ein weiteres Detail: Wenn Sie die Nextcloud hinter einem Reverse-Proxy betreiben, muss nicht der interne Server das Zertifikat halten, sondern der Proxy. Der Traffic zwischen Proxy und Nextcloud kann dann unverschlüsselt laufen, was in manchen Fällen in Ordnung ist, aber oft übersehen wird. Wer hier aus Sicherheitsgründen eine Ende-zu-Ende-Verschlüsselung will, muss auch auf dieser internen Strecke ein Zertifikat auflegen – sei es selbstsigniert oder aus der lokalen CA. Das ist nicht falsch, aber dann muss der Proxy dem internen Zertifikat vertrauen, und die Nextcloud-Instanz muss wiederum die IP des Proxys als vertrauenswürdig einstufen (Stichwort Reverse-Proxy-Konfiguration in der config.php).

Automatisierung ist alles – aber nicht jede Automatisierung taugt etwas

Wer seine Nextcloud professionell betreibt, kommt an einer automatischen Zertifikatserneuerung nicht vorbei. Der manuelle Aufwand, alle 90 Tage (Standard bei Let’s Encrypt) die Dateien zu tauschen und den Server neuzustarten, ist auf Dauer nicht praktikabel. Certbot macht das mit systemd-Timern recht zuverlässig. Aber ich habe schon Fälle erlebt, in denen der Timer nicht aktiviert war, weil der Admin vergessen hatte, den entsprechenden Service zu starten. Das klingt banal, ist aber häufiger als gedacht.

Die ACME-Implementierung in Form von acme.sh oder dehydrated gibt etwas mehr Kontrolle, verlangt aber auch mehr Verständnis für die Abläufe. Besonders die DNS-API-Integration ist eine feine Sache: Damit kann man Zertifikate für Domains ausstellen, die gar nicht auf dem öffentlichen Internet liegen – zum Beispiel interne Subdomains, die nur im Firmen-DNS aufgelöst werden. Das erfordert aber, dass der ACME-Client die Berechtigung hat, beim DNS-Provider (z. B. Cloudflare, AWS Route53, Hetzner) Einträge zu setzen. Das mag wie eine kleine Hürde wirken, aber wer sich einmal damit befasst hat, wird die Kontrolle schätzen – und nie wieder per Webinterface ein Zertifikat hochladen.

Ein interessantes Projekt ist „lego“ von Go-Acme, ein ACME-Client in Go, der sehr viele DNS-Provider unterstützt und sich gut in Skripte einbinden lässt. Damit kann man vor dem Renewal noch einen Hook ausführen, der den Webserver graceful neu lädt. So bleibt der Dienst unterbrechungsfrei.

Nextcloud-App „Security“ – was die Administration über Zertifikate anzeigt

Nextcloud hat eine App oder eher eine integrierte Sicherheitsüberprüfung, die in den Administratoreinstellungen zu finden ist (früher unter „Sicherheit & Prüfungen“). Sie zeigt unter anderem an, ob der Server per HTTPS erreichbar ist, ob das Zertifikat gültig ist und ob eine HSTS-Richtlinie (HTTP Strict Transport Security) gesetzt ist. Das ist ein gutes Instrument, um einen ersten Eindruck zu gewinnen. Aber es ist kein Ersatz für eine vollständige Zertifikatsverwaltung. Denn die Überprüfung bezieht sich nur auf den aktuellen Status – sie sagt nichts über die Verfallsdauer oder die korrekte Kette aus. Wer in der Administrationsoberfläche eine grüne Ampel sieht, kann sich nicht immer darauf verlassen, dass die Zertifikatskonfiguration auch in einer Woche noch hält.

Auch die sogenannte „HSTS-Konfiguration“ ist ein Thema. Sie wird im Webserver gesetzt und zwingt Clients, die Domäne ausschließlich per HTTPS zu erreichen. Das ist sinnvoll, aber wer das Zertifikat später wechselt oder die Domain ändert, kann Probleme bekommen, weil der HSTS-Eintrag im Browser oft für Monate gespeichert wird. Dann wird ein neues Zertifikat nicht akzeptiert, wenn die Domain nicht exakt übereinstimmt. Das erlebt man besonders bei Migrationen, wenn man von cloud.alt.de auf cloud.neu.de umzieht und die alte Domain per HSTS noch im Browser der User hängt. Also Vorsicht bei der Einrichtung – und immer einen Plan B haben.

Fehlerbehandlung: Wenn die Zertifikatskette nicht stimmt

Ein sehr häufiger Fehler: Die Zertifikatskette ist nicht vollständig. Viele Administratoren liefern nur das Blatt-Zertifikat aus, vergessen aber das Zwischenzertifikat (Intermediate CA). Moderne Browser können das zwar manchmal selbst ergänzen, aber ältere Clients oder die Nextcloud-Desktop-Apps nicht. Dann erscheint eine Fehlermeldung wie „Zertifikatskette unvollständig“. Die Lösung ist einfach: Man muss die gesamte Kette in der Server-Konfiguration angeben, am besten als Datei, in der das Blatt-Zertifikat oben und die Zwischen-CAs darunter stehen. Apache und Nginx können das.

Ein weiterer Punkt: Das Format. Die meisten Zertifikate werden als PEM (Base64-kodiert) ausgeliefert. Manche Anwendungen verlangen aber PKCS#12 oder DER. Nextcloud selbst ist hier tolerant, da die Entschlüsselung auf dem Webserver passiert. Aber wenn Sie Clients mit .p12-Dateien versorgen möchten, müssen Sie konvertieren – mit OpenSSL-Befehlen wie: openssl pkcs12 -export -inkey key.pem -in cert.pem -certfile chain.pem -out cert.p12. Das ist nicht Nextcloud-spezifisch, aber gehört zum Handwerkszeug.

Mehrere Nextcloud-Instanzen und Zertifikatsverwaltung

Große Organisationen betreiben oft mehrere Nextcloud-Instanzen für verschiedene Abteilungen oder Standorte. Dann stellt sich die Frage, ob jede Instanz ein eigenes Zertifikat bekommt oder ein Wildcard-Zertifikat für *.beispiel.de ausreicht. Technisch beides möglich. Aber aus Sicherheitssicht ist ein Wildcard-Zertifikat ein Kompromiss: Wenn der private Schlüssel einer Subdomain kompromittiert wird, sind alle Subdomains betroffen. Moderne ACME-Clients unterstützen zwar Wildcards, aber nur über DNS-Validierung. Die Verwaltung eines Wildcard-Zertifikats erfordert zudem eine sorgfältige Zugriffskontrolle auf den privaten Schlüssel – oft ein einzelner Punkt, den es zu schützen gilt.

Praktikabel ist die Variante mit separaten Zertifikaten für jede Instanz, wenn man ohnehin ACME automatisiert hat. Der Aufwand ist nach der Einrichtung minimal. Und jeder Fehler betrifft nur eine Instanz. Wer auf Nummer sicher gehen will, legt pro Instanz einen eigenen ACME-Client-Ordner an und lässt die Erneuerung eigenständig laufen. Das erzeugt zwar ein Dutzend Cronjobs, aber das ist verkraftbar.

Die Rolle von „Nextcloud Talk“ und der Zertifikatsprüfung

Wer die Nextcloud-App „Talk“ für Video- und Sprachkonferenzen nutzt, sollte sich der zusätzlichen Anforderungen bewusst sein. Talk benötigt eine Verbindung zu einem STUN/TURN-Server, der die Medienströme überträgt. Auch dieser Server muss ein gültiges Zertifikat haben, sonst brechen die Verbindungen ab oder werden nicht aufgebaut. Oft wird der TURN-Server auf einem anderen Port (zum Beispiel 3478 für UDP) betrieben, aber die Zertifikatsvalidierung über TLS erfolgt trotzdem – und wenn hier ein selbstsigniertes Zertifikat liegt, funktioniert das Ganze nicht. Also auch hier: die Zertifikatskette prüfen, den gesamten Stack testen. Das wird oft übersehen, weil die Nextcloud-Seite selbst läuft, aber die Talk-Verbindung im Hintergrund fehlschlägt.

Ein Tipp, der sich bewährt hat: Verwenden Sie die gleiche Domain für den TURN-Server wie für die Nextcloud-Instanz, dann gilt das Zertifikat automatisch mit. Aber wenn der TURN-Server auf einem separaten Subdomain liegt (z. B. turn.beispiel.de), dann braucht diese Domain ein eigenes Zertifikat.

Ein Blick auf die Zukunft: Zertifikatsmanagement in der Cloud

Die Entwicklung geht dahin, dass sich Zertifikate mehr und mehr automatisieren lassen. Der ACME-Standard hat sich durchgesetzt, und viele kommerzielle CAs bieten ihn inzwischen ebenfalls an. Für Nextcloud bedeutet das: kein Grund mehr, für ein Zertifikat Geld auszugeben, es sei denn, man braucht spezielle Features wie Organisation-Validierung (OV) oder Extended Validation (EV). In den meisten Fällen ist Let’s Encrypt ausreichend.

Aber die Verwaltung bleibt eine Disziplin für sich. Wer das nicht selbst machen möchte, kann auf Dienste wie Cloudflare oder AWS Certificate Manager setzen, die die Zertifikatsausstellung und -erneuerung komplett übernehmen. Allerdings koppelt man sich dann an einen externen Dienst, was nicht jedem Unternehmen gefällt. Open Source pur ist dann doch die Alternative: Ein eigener ACME-Server mit Step-CA, der die Zertifikate für alle internen Dienste ausstellt – und die Nextcloud eben auch. Das setzt aber voraus, dass man eine Public-Key-Infrastruktur (PKI) betreibt, was wiederum Know-how erfordert. Wer diesen Weg geht, sollte die CA überwachen und regelmäßige Backups des privaten CA-Schlüssels anlegen – denn wenn dieser flöten geht, sind alle ausgestellten Zertifikate ungültig.

Praktische Tipps für den Admin-Alltag

Abschließend ein paar Handgriffe, die sich in der täglichen Arbeit bewährt haben. Erstens: Führen Sie ein Zertifikatsinventar. Notieren Sie sich, für welche Domains Zertifikate laufen, wann sie ablaufen und wo die privaten Schlüssel gespeichert sind. Ein einfaches Spreadsheet oder ein Wiki-Eintrag reicht. Zweitens: Richten Sie eine Überwachung ein. Viele Tools wie Grafana, Nagios oder Icinga können Zertifikate überwachen und warnen, wenn das Ablaufdatum näher rückt. Oder Sie nutzen den certbot-auto-renew-Hook, um eine E-Mail zu senden, wenn die Erneuerung fehlschlägt. Drittens: Testen Sie die Erneuerung nach einem Major-Update des Webservers oder der Nextcloud-Version. Gerade nach einem Upgrade kann es sein, dass der ACME-Client nicht mehr richtig läuft, weil sich die Pfade geändert haben oder der Webserver andere Konfigurationen erwartet.

Viertens: Seien Sie skeptisch gegenüber „all-in-one“-Docker-Containern, die Nextcloud und Webserver in einem Paket ausliefern. Oft ist die Zertifikatsverwaltung dort nur halbgar umgesetzt – da wird das Let’s-Encrypt-Zertifikat direkt im Container gespeichert und geht beim Neustart verloren. Besser: Trennen Sie Nextcloud und Reverse-Proxy (zum Beispiel Traefik oder nginx-proxy) und lassen Sie den Proxy das Zertifikatsmanagement machen. Traefik hat eine sehr ausgereifte ACME-Integration und erneuert Zertifikate automatisch, inklusive Hot-Reload. Das ist in Container-Umgebungen die eleganteste Lösung.

Ein letzter Punkt: Denken Sie an die Zertifikatsprüfung auf Client-Seite. Die Nextcloud-Desktop-Clients speichern Zertifikate von vertrauenswürdigen Servern und vergleichen sie bei jeder Verbindung. Wenn Sie das Zertifikat wechseln, ohne das alte ordentlich zu entwerten, kann es zu Konflikten kommen. Der Client meldet dann einen Zertifikatsfehler, weil die Identität nicht mehr passt. Dann hilft nur, die gespeicherten Zertifikate auf dem Client zu löschen oder den Server als vertrauenswürdig neu hinzuzufügen. Das ist kein Problem der Nextcloud selbst, sondern der Zertifikatsverwaltung im weiteren Sinne.

Fazit: Eine Frage der Disziplin, nicht der Technik

Die Nextcloud-Zertifikatsverwaltung ist kein Hexenwerk. Aber sie erfordert Disziplin und ein Verständnis dafür, wie die Komponenten zusammenspielen. Der Fehler vieler Administratoren liegt darin, die Verantwortung an den Webserver zu delegieren und sich dann nicht mehr darum zu kümmern. Das rächt sich spätestens, wenn das Zertifikat abläuft und die Mitarbeiter nicht mehr auf ihre Daten zugreifen können. Oder wenn ein Sicherheitsaudit bemängelt, dass die Zertifikatskette nicht korrekt ist.

Nextcloud selbst bietet an dieser Stelle keine magischen Werkzeuge – und das muss es auch nicht. Die Stärke von Nextcloud liegt in der Datenhaltung, der Synchronisation und der App-Integration. Die Sicherheit der Verbindung ist und bleibt eine Infrastrukturaufgabe. Wer diese Aufgabe ernst nimmt und in Automatisierung investiert, wird mit einem stabilen, wartungsarmen Betrieb belohnt. Und das ist doch letztlich das Ziel: eine Cloud, die funktioniert, ohne dass man ständig an der Konfiguration drehen muss.

Also: Richten Sie Ihren ACME-Client ein, testen Sie die Erneuerung, überwachen Sie die Laufzeit, und halten Sie die Übersicht über alle Zertifikate im Unternehmen. Dann kann die Nextcloud laufen – und die Zertifikate sind unsichtbar, so wie es sich für eine gute Infrastruktur gehört.