Home
» Hoe
»
Corrigeer WOPI-bewijsfouten door sleutels, ontdekking en URL's te controleren.
Corrigeer WOPI-bewijsfouten door sleutels, ontdekking en URL's te controleren.
Wanneer een WOPI-host de melding "bewijsvalidatie mislukt" of "Ongeldig WOPI-bewijs" geeft, controleer dan eerst welk systeem de afwijzing heeft geregistreerd. Als de opslaghost het ondertekende verzoek van Collabora afwijst, controleer dan het bewijs-sleutelpaar en het ontdekkingsantwoord voordat u de WOPI-host-whitelists wijzigt of bewijscontroles uitschakelt. Voor pakketinstallaties genereert Collabora normaal gesproken het sleutelpaar; voor Docker-, Kubernetes- en multi-replica-implementaties moet het paar worden aangeleverd en consistent worden opgeslagen.
Identificeer de fout in de controle voordat u de sleutels wijzigt.
De WOPI-bewijsvalidatie maakt gebruik van een ondertekend verzoek en de publieke sleutel die door de WOPI-client in de ontdekkingsmetadata wordt geadverteerd. Dit staat los van Collabora's lijst met vertrouwde WOPI-hosts, de TLS-certificaatvalidatie en de controle van het toegangstoken van de opslaghost. Het opnieuw genereren van een sleutel kan helpen wanneer de privésleutel ontbreekt of niet overeenkomt met de geadverteerde publieke sleutel, maar het kan een nieuwe mismatch veroorzaken als slechts één replica wordt gewijzigd of als een host nog steeds ontdekkingsgegevens in de cache heeft.
Een bericht aan de hostzijde dat ongeldigheid bevestigt, wijst in de eerste plaats op het moment van sleutelontdekking, het construeren van de handtekening of het verzoek.
Bewijs in het logboek
Waarschijnlijk gebied om te controleren
De opslaghost geeft de melding "Ongeldig WOPI-bewijs" bij het ontvangen van CheckFileInfo of een ander WOPI-verzoek.
Collabora's bewijssleutel, de ontdekkingsgegevens van de host, URL-reconstructie of tijdstempel
Collabora geeft aan: "Ongeautoriseerde WOPI-host" of "Geen acceptabele WOPI-hosts beschikbaar".
De WOPI-host-whitelist/domeinconfiguratie, niet de bewijssleutel.
Ongeldig token, verlopen token of toegang geweigerd zonder bewijsfout.
Door de host uitgegeven toegangstoken, machtigingen of vervaldatum van het token
Controleer één mislukte aanvraag in zowel de Collabora- als de storage-hostlogboeken; een laadpictogram in de browser alleen is geen indicatie van een fout met de proof-of-key.
Kies de reparatie die het beste bij de inzet past.
Begin met de minst ingrijpende optie. Controleer bij een pakketgebaseerde installatie eerst de bestaande sleutelbestanden en servicelogboeken; de huidige Collabora-documentatie geeft aan dat RPM- en Debian-pakketinstallaties automatisch een WOPI-bewijssleutelpaar genereren. Als deze bestanden aanwezig en stabiel zijn, is het roteren ervan meestal niet nodig.
Collabora gebruikt een privé-bewijssleutel en publiceert de bijbehorende publieke sleutel via WOPI-ontdekking.
Inzet
Aanbevolen actie
Afweging
Server met beheer van één enkel pakket
Bewaar het gegenereerde sleutelpaar; herstel de machtigingen of genereer het sleutelpaar opnieuw alleen als het ontbreekt of niet overeenkomt.
Minimale wijziging, maar controleer uw pakketversie en geconfigureerde paden.
Een enkele Docker-container
Genereer eenmalig een paar en monteer dit permanent in de container.
Vereist een persistent volume en correcte leesrechten voor coolwsd.
Kubernetes of meerdere replica's
Koppel één gedeeld geheim/sleutelpaar aan elke Collabora-instantie.
Consistente handtekeningen op alle replica's; rotatie moet ook de ontdekkingsweergave van de host bijwerken.
De host-URL is gewijzigd achter een proxy.
Controleer het openbare schema, de host, het pad en de queryreeks die worden gebruikt voor de validatie van de handtekening.
Het is ingewikkelder dan het roteren van sleutels, maar voorkomt onnodige wijzigingen in inloggegevens.
Volgens de handleiding van Collabora 24.04 bevat de openbare Docker-image geen proof-key-paar; genereer er een en koppel deze permanent. De officiële Helm-grafiek ondersteunt proof-key Secrets. Genereer nooit een apart paar voor elke replica, anders kan load balancing ervoor zorgen dat storingen zich af en toe voordoen.
Controleer en repareer het sleutelpaar op een veilige manier.
Zoek de geconfigureerde sleutelpaden. Controleer op de Collabora-host of in de container de coolwsd.xmlinstellingen voor het proof-key-pad en kijk of zowel de privésleutel als de publieke sleutel beschikbaar zijn. Deze bevinden zich meestal onder /etc/coolwsd/, maar de indeling van pakketten en containers kan verschillen. Plak de privésleutel nooit in logboeken, tickets of chatberichten.
Controleer of de sleutels overeenkomen. Vergelijk voor de standaardpaden de vingerafdrukken zonder de privésleutel weer te geven: sudo openssl pkey -in /etc/coolwsd/proof_key -pubout -outform DER | sha256sumen openssl pkey -pubin -in /etc/coolwsd/proof_key.pub -outform DER | sha256sum. De resulterende hashes moeten overeenkomen. Als uw paden verschillen, vervang ze dan door de daadwerkelijk geconfigureerde paden. Als de privésleutel niet leesbaar is, corrigeer dan het eigenaarschap en de machtigingen volgens het beveiligingsmodel van de service; maak deze niet voor iedereen leesbaar.
Genereer de privésleutel alleen opnieuw wanneer nodig. Als de privésleutel ontbreekt of het sleutelpaar niet overeenkomt, gebruik sudo coolconfig generate-proof-keydan de betreffende tool, waar deze is geïnstalleerd. Genereer voor Docker het sleutelpaar op een geschikte permanente locatie, koppel beide bestanden vervolgens waar Collabora ze verwacht en zorg ervoor dat het coolwsd-proces de privésleutel kan lezen. Gebruik op een beheerd platform het ondersteunde Secret-mechanisme in plaats van een draaiende pod handmatig te bewerken.
Zorg ervoor dat alle instanties consistent zijn. Implementeer voor replica's hetzelfde sleutelpaar op elke instantie en herstart of implementeer Collabora zodat de bestanden worden ingelezen. Vernieuw of herhaal vervolgens de WOPI-detectie op de opslaghost met behulp van het door die host ondersteunde mechanisme. Een sleutelrotatie wijzigt de publieke sleutel; caches of een andere replica die nog steeds de oude sleutel gebruikt, kunnen storingen voorkomen.
Replica's moeten één vast sleutelpaar delen, zodat elke instantie verzoeken consistent ondertekent.
Wanneer de sleutel overeenkomt, maar de bewijsvalidatie nog steeds mislukt
Controleer de tijdsynchronisatie op beide systemen. WOPI-bewijsverzoeken bevatten een tijdstempel; een host kan een oud of verlopen tijdstempel afwijzen. Controleer of NTP of de tijdservice van het platform correct werkt en of de servers logische UTC-tijden rapporteren. Versoepel de tijdstempelcontroles niet om een klokprobleem te omzeilen.
Controleer vervolgens de openbare URL die de host gebruikt om het ondertekende verzoek te reconstrueren. Het bewijs is gekoppeld aan de verzoek-URL, inclusief relevante queryparameters, en de WOPI-specificatie vereist dat de URL-representatie die voor validatie wordt gebruikt, overeenkomt met de ondertekende vorm. Een reverse proxy die HTTPS beëindigt, kan ervoor zorgen dat de applicatie een interne HTTP-URL ziet, zelfs als Collabora de openbare HTTPS-URL heeft ondertekend. Configureer de headers voor vertrouwde proxy's en de externe URL-instellingen van de applicatie volgens de officiële richtlijnen van de WOPI-host; herschrijf de bewijslogica niet en verwijder geen queryparameters.
Als de verificatie pas na een sleutelrotatie mislukt, vernieuw dan de ontdekking en controleer of alle Collabora-replica's dezelfde publieke sleutel beschikbaar stellen. Als alleen verzoeken die via één proxy of één replica worden gerouteerd mislukken, vergelijk dan de logboeken en configuratie van dat pad in plaats van de sleutel opnieuw te roteren. Het uitschakelen van verificatie kan een beveiligingscontrole verzwakken en mag niet als tijdelijke oplossing in een productieomgeving worden gebruikt.
Controleer de reparatie.
Haal het Collabora-ontdekkingseindpunt op uit het netwerk van de opslaghost en bevestig dat het actuele bewijssleutelmetadata retourneert.
Open een testdocument en controleer of de opslaghost het CheckFileInfo-verzoek en de daaropvolgende documentverzoeken accepteert zonder een ongeldigheidsfout.
Herhaal dit voor elke proxyroute of replica en controleer vervolgens of het sleutelpaar gekoppeld blijft na een herstart van de container of vervanging van de pod.
Bevestig de reparatie door een document te openen en te controleren of de host de WOPI-verzoeken accepteert.
Een succesvolle documentopening bevestigt alleen dat pad; herhaal de controle voor elke WOPI-host en proxyroute die u gebruikt.