So beheben Sie den Fehler „WOPI-Beweisvalidierung fehlgeschlagen“ in Collabora Online

Beginnen Sie mit dem System, das den Fehler protokolliert hat.

Die Meldung „WOPI-Nachweisvalidierung fehlgeschlagen“ bedeutet, dass ein WOPI-Host eine signierte Anfrage von Collabora Online nicht verifizieren konnte. In einer typischen Nextcloud Office-Umgebung fungiert Nextcloud als WOPI-Host und Collabora als WOPI-Client: Collabora sendet die signierte Anfrage, und der Host prüft sie. Die genaue Formulierung variiert je nach Integration und Version. Ermitteln Sie daher zunächst, welche Komponente die Meldung ausgegeben hat und welche Anfrage fehlgeschlagen ist.

Der Nachweis dient der Sicherheitsprüfung und ist kein allgemeiner Verbindungstest. Er verknüpft eine Anfrage mit dem Zugriffstoken, der vollständigen Anfrage-URL und einem Zeitstempel und signiert diese Daten anschließend mit dem privaten Nachweisschlüssel von Collabora. Der Host verifiziert die Signatur mithilfe eines öffentlichen Nachweisschlüssels, der in Collaboras Discovery-XML veröffentlicht ist. Die WOPI-Protokolldefinition beschreibt die signierten Felder und Header.

Erste Maßnahme: Reproduzieren Sie den Fehler einmal, notieren Sie Uhrzeit, Dateiaktion, HTTP-Status und Anfrage- oder Korrelations-ID und überprüfen Sie anschließend sowohl das Protokoll der Speicherplattform als auch coolwsddas Protokoll von Collabora auf dasselbe Ereignis. Posten Sie keine Zugriffstoken, Proof-Header oder privaten Schlüssel in einem Ticket.

Schnelldiagnosetabelle

1. Die Bestätigungs-Discovery legt den aktuellen öffentlichen Schlüssel offen.

Collabora veröffentlicht seine WOPI-Funktionen und Informationen zum Beweisschlüssel am Discovery-Endpunkt. Überprüfen Sie von einem Rechner aus, der die von Ihrem Speicherserver verwendete Collabora-URL erreichen kann:

curl -fsS https://office.example.com/hosting/discovery

Suchen Sie im XML nach einem proof-keyElement mit einem aktuellen Wert valueund, falls vorhanden, einem Schlüssel oldvalue. Verwechseln Sie diese öffentlichen Daten nicht mit dem auf dem Collabora-Server gespeicherten privaten Schlüssel. Der aussagekräftigste Vergleich ist die vom WOPI-Host selbst abgerufene Discovery-Antwort, da ein Browser oder die Workstation eines Administrators über DNS, einen Proxy oder einen Cache eine andere Antwort erhalten kann.

Bestätigt: Die WOPI-Integration von Collabora verwendet Signaturnachweise, und der öffentliche Schlüssel wird über die Discovery-Funktion bereitgestellt. Vorgehensweise: Rufen Sie die Discovery-Informationen vom Host/Container ab, der die Anfragen validiert, und prüfen Sie anschließend, ob das XML gültig ist und mit dem in der Speicherplattform konfigurierten Collabora-Endpunkt übereinstimmt. Die Dokumentation zur Generierung des Signaturnachweises und zum Discovery-Verhalten finden Sie im Collabora SharePoint-Bindungsleitfaden .

2. Prüfen Sie, ob der private Schlüssel existiert und lesbar ist.

Prüfen Sie bei Collabora das Startprotokoll auf Warnungen, dass die Proof-Key-Datei fehlt oder nicht lesbar ist. Der Collabora-Dienst muss den privaten Schlüssel zum Signieren lesen können. Bei paketierten Bereitstellungen können Konfigurationspfad und Dienstkonto variieren. Prüfen Sie daher das konfigurierte Verzeichnis des Dienstes und die zugehörigen Container-Volumes, anstatt vom Hostpfad auszugehen.

Collabora dokumentiert coolconfig generate-proof-keyFälle, in denen die automatische Schlüsselkonfiguration fehlgeschlagen ist. Führen Sie diesen Befehl nicht routinemäßig zur Fehlerbehebung auf einem funktionierenden Cluster aus. Die Generierung eines neuen Schlüssels ändert die Signaturidentität. Wenn der Speicherserver weiterhin einer älteren Erkennungsantwort vertraut, können Anfragen so lange fehlschlagen, bis der Host den verwendeten öffentlichen Schlüssel aktualisiert.

sudo coolconfig generate-proof-key

Verwenden Sie diesen Befehl erst, nachdem Sie sichergestellt haben, dass der Schlüssel fehlt oder ungültig ist, und nachdem Sie geplant haben, wie jeder Collabora-Knoten und WOPI-Host die entsprechenden Schlüsselinformationen erhält. Befolgen Sie anschließend die in Ihrer Paket- oder Containerbereitstellung dokumentierte Vorgehensweise zum Neuladen des Dienstes und rufen Sie die Erkennung über den Netzwerkpfad des Validators erneut ab.

3. Suchen Sie nach Schlüsselabweichungen zwischen den Knoten oder Caches.

Ein einzelner Collabora-Server kann funktionieren, während eine Load-Balancing-Umgebung zeitweise ausfällt. Beispielsweise kann ein Knoten einen neu generierten privaten Schlüssel verwenden, während ein anderer noch mit dem alten Schlüssel signiert; ein Host mit zwischengespeicherten Discovery-Daten vertraut möglicherweise keinem der beiden Schlüssel dauerhaft. Dies ist eine von der Umgebung abhängige Ursache und kein Beweis dafür, dass jeder sporadische Fehler durch die Schlüsselrotation verursacht wird.

Aktion: Daten über den Load Balancer und, falls zulässig, direkt von jedem Backend abrufen /hosting/discovery. Die Werte der öffentlichen Schlüssel vergleichen und prüfen, ob der Discovery-Cache des WOPI-Hosts aktuell ist. Falls Knoten absichtlich separate Schlüssel verwenden, prüfen, ob die Speicherintegration diese Topologie unterstützt. Andernfalls die Konfiguration des Proof-Keys im gesamten Cluster konsistent halten. Die Aktualisierung der Discovery sollte über den von der Integration unterstützten Mechanismus erfolgen. Datenbank-Caches dürfen nicht ohne triftigen Grund bearbeitet oder nicht zugehörige Dienste neu gestartet werden.

4. Vergleichen Sie die signierte URL mit der vom Host validierten URL.

Der Nachweis umfasst die absolute WOPI-Anfrage-URL in Großbuchstaben sowie das Token und den Zeitstempel. Daher ist URL-Rewriting relevant. Ein Reverse-Proxy kann den extern sichtbaren Hostnamen, das Schema, den Port, den Pfad oder die Maskierung ändern. Signiert Collabora eine Anfrage für eine bestimmte URL, rekonstruiert der WOPI-Host jedoch eine andere URL zur Verifizierung, kann eine korrekte Signatur ungültig erscheinen.

Maßnahme: Korrelieren Sie eine fehlgeschlagene Anfrage auf Proxy- und Anwendungsebene. Vergleichen Sie Schema, Hostname, expliziten Port, Pfad und kodierte Zeichen, die vom Validator erkannt werden, mit der URL im Validierungscode. Überprüfen Sie die Verarbeitung von forwarded-host und forwarded-proto nur, wenn die Anwendung auf diese Header angewiesen ist. Behalten Sie die tatsächliche Anfrage-URL bei; beheben Sie das Problem nicht, indem Sie Signaturprüfungen deaktivieren oder beliebigen weitergeleiteten Headern vertrauen.

5. Zeitstempel- und Byte-Verarbeitung validieren

Der WOPI-Beweis enthält einen X-WOPI-TimeStampHeader. In der Microsoft WOPI-Spezifikation ist dieser Header eine 64-Bit-Ganzzahl, gemessen in 100-Nanosekunden-Intervallen seit dem 1. Januar 0001, und kein Unix-Zeitstempel in Sekunden. Ein benutzerdefinierter Validator, der ihn als Unix-Sekunden interpretiert, Ziffern weglässt, die Kodierung ändert oder die signierten Bytes falsch zusammensetzt, kann gültige Anfragen ablehnen.

Eine mögliche Ursache für Zeitabweichungen, wenn ein Host ein Aktualitätsfenster erzwingt, ist eine Abweichung der Systemzeit. Die genaue Toleranz hängt jedoch von der Validierungsimplementierung ab. Microsoft empfiehlt für Microsoft 365 im Web eine Altersprüfung nach 20 Minuten. Gehen Sie nicht davon aus, dass dieser Wert für jede Collabora-Integration gilt. Maßnahmen: Überprüfen Sie die NTP-Synchronisierung und die UTC-Zeit auf den Collabora- und Speichersystemen und prüfen Sie anschließend die dokumentierte Zeitstempelregel und den zugehörigen Parsing-Code des Hosts.

Prüfen Sie außerdem die Byte-Ebenen-Struktur, wenn Sie einen benutzerdefinierten WOPI-Host verwenden. Das Token ist UTF-8-kodiert; die Längenangaben beziehen sich auf die Byteanzahl; die URL ist die vollständige absolute URL in Großbuchstaben; und der Zeitstempelwert muss exakt wie angegeben dargestellt werden. Der öffentliche Schlüssel muss mit dem privaten Schlüssel der Collabora-Instanz übereinstimmen, die die Anfrage gesendet hat.

6. Trennen Sie Nachweisfehler von Fehlern in der Zulassungsliste und TLS-Fehlern.

Eine WOPI-Host-Zulassungsliste legt fest, welche Speicherhosts Collabora kontaktieren darf. Die TLS-Validierung entscheidet, ob das Zertifikat eines Netzwerkpartners vertrauenswürdig ist. Die Nachweisvalidierung prüft die Signatur einer WOPI-Anfrage. Diese Kontrollmechanismen dienen der sicheren Integration, sind aber nicht austauschbar. Das Hinzufügen eines Hosts zu einer Zulassungsliste behebt keine Signaturabweichung; das Deaktivieren der TLS-Prüfungen korrigiert keinen veralteten öffentlichen Nachweisschlüssel.

Für Nextcloud-Bereitstellungen empfiehlt der offizielle Leitfaden zur Fehlerbehebung, die erforderlichen HTTP(S)-Pfade in beide Richtungen zu prüfen, die Nextcloud- und Collabora-Protokolle einzusehen und die Einträge in der WOPI-Host-Zulassungsliste auf Warnungen zu überprüfen. Vorgehensweise: Befolgen Sie die Fehlerkategorie im Protokoll. Testen Sie den Discovery-Endpunkt und die Netzwerkerreichbarkeit separat vom Proof-Validator. Erweitern Sie die Zulassungsliste nicht *als Workaround.

Sichere Wiederherstellungssequenz

1. Erfassen Sie den genauen Zeitpunkt des Fehlschlagens der Anfrage und ermitteln Sie, welcher Dienst den Fehler bei der Nachweisvalidierung protokolliert hat.
2. Prüfen Sie die Collabora-Protokolle auf Warnungen wegen fehlender Schlüssel; untersuchen Sie das Discovery-XML vom Netzwerkpfad des WOPI-Hosts.
3. Vergleichen Sie den öffentlichen Schlüssel in der Erkennungsphase mit dem privaten Schlüssel und der Knotenkonfiguration, die zum Signieren der Anfrage verwendet wurden.
4. Überprüfen Sie die Konsistenz des Load Balancers, das Discovery-Caching und alle kürzlich vorgenommenen Änderungen an Schlüsseln, Hostnamen, Proxys oder TLS.
5. Vergleichen Sie die signierte Anfrage-URL und die Zeitstempelverarbeitung, ohne Token oder Beweis-Header offenzulegen.
6. Führen Sie einen erneuten Test mit einem Dokument durch und vergewissern Sie sich in den Host-Protokollen, dass die gleiche Anfrage erfolgreich ist, bevor Sie den normalen Datenverkehr wiederherstellen.

Falls der Fehler weiterhin besteht, erfassen Sie bitte die bereinigten Protokolle beider Seiten, die Collabora- und Speicherversionen, den Bereitstellungstyp, ob ein oder mehrere Knoten beteiligt sind, das Discovery-XML ohne Geheimnisse sowie die Proxy-Route der fehlerhaften Anfrage. Teilen Sie diese Informationen dem zuständigen Anbieter oder den Integrationsverantwortlichen mit. Die genaue Fehlermeldung allein reicht nicht aus, um festzustellen, ob die Ursache veraltete Discovery-Daten, URL-Kanonisierung, ein Problem mit der Uhrzeit oder ein Fehler im benutzerdefinierten Validator ist; die Informationen auf Anfrageebene bestimmen die weitere Vorgehensweise.