Hoe los ik de foutmelding "WOPI Proof Validation Failed" op in Collabora Online?

Begin met het systeem dat de fout heeft geregistreerd.

"WOPI-bewijsvalidatie mislukt" betekent dat een WOPI-host een ondertekend verzoek van Collabora Online niet kon verifiëren. In een typische Nextcloud Office-configuratie is Nextcloud de WOPI-host en Collabora de WOPI-client: Collabora verzendt het ondertekende verzoek en de host controleert het. De exacte formulering verschilt per integratie en release, dus achterhaal eerst welke component het bericht heeft verzonden en welk verzoek is mislukt.

Het bewijs is een beveiligingscontrole, geen algemene connectiviteitstest. Het koppelt een verzoek aan het toegangstoken, de volledige URL van het verzoek en een tijdstempel, en ondertekent die gegevens vervolgens met de privé-bewijssleutel van Collabora. De host verifieert de handtekening met behulp van een openbare bewijssleutel die is gepubliceerd in de discovery XML van Collabora. De WOPI-protocoldefinitie beschrijft de ondertekende velden en headers.

Eerste actie: reproduceer de fout eenmaal, noteer het tijdstip, de bestandsactie, de HTTP-status en de aanvraag- of correlatie-ID, en controleer vervolgens zowel het logboek van het opslagplatform als coolwsdhet logboek van Collabora op dezelfde gebeurtenis. Plaats geen toegangstokens, proofheaders of privésleutels in een ticket.

Snelle diagnose tabel

1. Bevestig dat de ontdekking de huidige publieke sleutel onthult.

Collabora publiceert zijn WOPI-mogelijkheden en proof-key-informatie op het discovery-eindpunt. Controleer vanaf een machine die de Collabora-URL van uw opslagserver kan bereiken het volgende:

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

Zoek in de XML naar een proof-keyelement met een huidige waarde valueen, indien aanwezig, een oldvalue. Verwar dit openbare materiaal niet met de privésleutel die op de Collabora-server is opgeslagen. De meest bruikbare vergelijking is het ontdekkingsantwoord dat door de WOPI-host zelf wordt opgehaald, omdat een browser of een werkstation van een beheerder een ander antwoord kan ontvangen via DNS, een proxy of een cache.

Geverifieerd: De WOPI-integratie van Collabora maakt gebruik van bewijshandtekeningen en de publieke sleutel wordt beschikbaar gesteld via discovery. Actie: haal discovery op van de host/container die de verzoeken valideert en controleer vervolgens of de XML geldig is en overeenkomt met het Collabora-eindpunt dat is geconfigureerd in het opslagplatform. De Collabora SharePoint-bindingshandleiding beschrijft het genereren van bewijssleutels en het discovery-gedrag.

2. Controleer of de privésleutel bestaat en leesbaar is.

Controleer bij Collabora het opstartlogboek op waarschuwingen dat het bewijssleutelbestand ontbreekt of onleesbaar is. De Collabora-service moet de privésleutel kunnen lezen om te kunnen ondertekenen. Bij pakketimplementaties kunnen het configuratiepad en het serviceaccount variëren; controleer de geconfigureerde directory van de service en de bijbehorende containervolumes in plaats van uit te gaan van een hostpad.

Collabora-documentatie is coolconfig generate-proof-keybedoeld voor gevallen waarin de automatische sleutelconfiguratie niet werkte. Voer deze niet uit als een standaardopdracht voor probleemoplossing op een werkend cluster. Het genereren van een nieuwe sleutel wijzigt de ondertekeningsidentiteit. Als de opslagzijde nog steeds een oudere ontdekkingsreactie vertrouwt, kunnen verzoeken blijven mislukken totdat de host de gebruikte publieke sleutel vernieuwt.

sudo coolconfig generate-proof-key

Gebruik die opdracht alleen nadat u hebt bevestigd dat de sleutel ontbreekt of ongeldig is en nadat u hebt gepland hoe elk Collabora-knooppunt en elke WOPI-host de bijbehorende sleutelinformatie zal ontvangen. Volg vervolgens de gedocumenteerde procedure voor het herladen van de service van uw pakket- of containerimplementatie en haal de ontdekking opnieuw op via het netwerkpad van de validator.

3. Zoek naar inconsistenties in de sleutels tussen knooppunten of caches.

Een enkele Collabora-server kan probleemloos werken, terwijl een load-balanced implementatie af en toe uitvalt. Het kan bijvoorbeeld voorkomen dat één node een nieuw gegenereerde privésleutel heeft, terwijl een andere nog steeds met de oude sleutel ondertekent; een host met gecachede discovery-gegevens vertrouwt mogelijk geen van beide sleutels consistent. Dit is een oorzaak die afhankelijk is van de implementatie, en geen bewijs dat elke intermitterende fout wordt veroorzaakt door sleutelrotatie.

Actie: haal de gegevens op /hosting/discoveryvia de load balancer en, indien toegestaan, rechtstreeks van elke backend. Vergelijk de waarden van de publieke sleutels en controleer of de discovery-cache van de WOPI-host actueel is. Als knooppunten opzettelijk aparte sleutels gebruiken, controleer dan of de opslagintegratie die topologie ondersteunt; zorg er anders voor dat de configuratie van de bewijssleutel consistent is in het hele cluster. Het vernieuwen van de discovery-cache moet gebruikmaken van het door de integratie ondersteunde mechanisme. Vermijd het bewerken van een databasecache of het herstarten van niet-gerelateerde services zonder bewijs.

4. Vergelijk de ondertekende URL met de URL die de host valideert.

Het bewijs omvat de absolute WOPI-verzoek-URL in hoofdletters, evenals het token en de tijdstempel. Dit maakt URL-herschrijving relevant. Een reverse proxy kan de extern zichtbare hostnaam, het schema, de poort, het pad of de escape-tekens wijzigen. Als Collabora een verzoek voor een bepaalde URL ondertekent, maar de WOPI-host een andere URL reconstrueert voor verificatie, kan een correcte handtekening ongeldig lijken.

Actie: correleer een mislukte aanvraag op proxy- en applicatieniveau. Vergelijk het schema, de hostnaam, de expliciete poort, het pad en de gecodeerde tekens die de validator ziet met de URL die in de proof-validatiecode wordt gebruikt. Controleer de afhandeling van forwarded-host en forwarded-proto alleen als de applicatie op deze headers vertrouwt. Behoud de echte aanvraag-URL; los het probleem niet op door handtekeningcontroles uit te schakelen of willekeurige doorgestuurde headers te vertrouwen.

5. Valideer de verwerking van tijdstempels en bytes.

Het WOPI-bewijs bevat X-WOPI-TimeStamp. In de Microsoft WOPI-specificatie is deze header een 64-bits integer, gemeten in intervallen van 100 nanoseconden sinds 1 januari 0001, en geen Unix-timestamp in seconden. Een aangepaste validator die dit interpreteert als Unix-seconden, cijfers weglaat, de codering wijzigt of de ondertekende bytes onjuist samenstelt, kan geldige verzoeken afwijzen.

Een mogelijke oorzaak van een tijdsverschil is wanneer een host een venster voor de actualiteit van gegevens hanteert, maar de exacte tolerantie hangt af van de implementatie die de validatie uitvoert. De richtlijnen van Microsoft voor Microsoft 365 voor het web gebruiken een controle op de actualiteit van gegevens van 20 minuten; ga er niet vanuit dat dit getal van toepassing is op elke Collabora-integratie. Actie: controleer de NTP-synchronisatie en de UTC-tijd op de Collabora- en opslagsystemen en inspecteer vervolgens de gedocumenteerde tijdstempelregel en de parseercode van de host.

Controleer ook de constructie op byte-niveau als u een aangepaste WOPI-host beheert. Het token is UTF-8; lengtes worden weergegeven als byte-tellingen; de URL is de volledige absolute URL in hoofdletters; en de tijdstempelwaarde moet exact worden weergegeven zoals gespecificeerd. De publieke sleutel moet overeenkomen met de privésleutel die wordt gebruikt door de Collabora-instantie die het verzoek heeft verzonden.

6. Scheid bewijsfouten van fouten in de whitelist en TLS-fouten.

Een WOPI-host-whitelist bepaalt met welke opslaghosts Collabora contact mag opnemen. TLS-validatie bepaalt of het certificaat van een netwerkpartner betrouwbaar is. Proof-validatie controleert de handtekening van een WOPI-verzoek. Deze controles hebben betrekking op veilige integratie, maar ze zijn niet uitwisselbaar. Het toevoegen van een host aan een whitelist lost een mismatch in de handtekening niet op; het uitschakelen van TLS-controles corrigeert een verouderde publieke proof-sleutel niet.

Voor Nextcloud-implementaties adviseert de officiële handleiding voor probleemoplossing om de vereiste HTTP(S)-paden in beide richtingen te controleren, de Nextcloud- en Collabora-logboeken te bekijken en de vermeldingen in de WOPI-host-whitelist te controleren op waarschuwingen. Actie: volg de foutcategorie in het logboek. Test het discovery-eindpunt en de netwerkbereikbaarheid afzonderlijk van de proof-validator. Verbreed een whitelist niet als *tijdelijke oplossing.

Veilige herstelprocedure

1. Leg het exacte tijdstip vast waarop het verzoek mislukte en identificeer welke service de validatiefout heeft geregistreerd.
2. Controleer de Collabora-logboeken op waarschuwingen over ontbrekende sleutels; inspecteer de ontdekkings-XML van het netwerkpad van de WOPI-host.
3. Vergelijk de publieke sleutel in de ontdekking met de privésleutel en de knooppuntconfiguratie die gebruikt zijn om het verzoek te ondertekenen.
4. Controleer de consistentie van de load balancer, de cache voor ontdekkingen en eventuele recente wijzigingen in sleutels, hostnamen, proxy's of TLS-instellingen.
5. Vergelijk de URL van het ondertekende verzoek en de afhandeling van de tijdstempel zonder tokens of bewijsheaders weer te geven.
6. Test het opnieuw met één document en controleer of hetzelfde verzoek in de hostlogboeken succesvol is voordat u het normale verkeer herstelt.

Als de fout aanhoudt, verzamel dan geanonimiseerde logbestanden van beide kanten, inclusief Collabora- en opslagversies, implementatietype, of er één of meerdere knooppunten bij betrokken zijn, de discovery XML (zonder geheimen) en de proxyroute voor het mislukte verzoek. Deel deze informatie met de betreffende leverancier of de beheerders van de integratie. De exacte foutmelding alleen geeft geen uitsluitsel over de oorzaak: verouderde discovery, URL-canonicalisatie, een klokprobleem of een bug in een aangepaste validator; de gegevens op verzoekniveau bepalen welke aanpak nodig is.