How to Fix “WOPI Proof Validation Failed” in Collabora Online

Start with the system that logged the failure

“WOPI proof validation failed” means a WOPI host could not verify a signed request from Collabora Online. In a typical Nextcloud Office setup, Nextcloud is the WOPI host and Collabora is the WOPI client: Collabora sends the signed request, and the host checks it. The exact wording varies by integration and release, so first identify which component emitted the message and which request failed.

The proof is a security check, not a general connectivity test. It binds a request to the access token, the full request URL, and a timestamp, then signs that data with Collabora’s private proof key. The host verifies the signature using a public proof key published in Collabora’s discovery XML. The WOPI protocol definition describes the signed fields and headers.

First action: reproduce the failure once, note the time, file action, HTTP status, and request or correlation ID, then inspect both the storage platform’s log and Collabora’s coolwsd log for the same event. Do not post access tokens, proof headers, or private keys in a ticket.

Fast diagnosis table

1. Confirm discovery exposes the current public key

Collabora publishes its WOPI capabilities and proof-key information at the discovery endpoint. From a machine that can reach the Collabora URL used by your storage server, inspect:

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

Look in the XML for a proof-key element with a current value and, where present, an oldvalue. Do not confuse this public material with the private key stored on the Collabora server. The most useful comparison is the discovery response fetched by the WOPI host itself, because a browser or an administrator’s workstation may receive a different response through DNS, a proxy, or a cache.

Verified: Collabora’s WOPI integration uses proof signatures, and the public key is made available through discovery. Action: fetch discovery from the actual host/container that validates requests, then confirm the XML is valid and matches the Collabora endpoint configured in the storage platform. The Collabora SharePoint binding guide describes proof-key generation and discovery behavior.

2. Check whether the private key exists and is readable

On Collabora, inspect the startup log for warnings that the proof-key file is missing or unreadable. The Collabora service must be able to read the private key for signing. For packaged deployments, the configuration path and service account can vary; check the service’s configured directory and its container volume mounts rather than assuming a host path.

Collabora documents coolconfig generate-proof-key for cases where automatic key setup did not work. Do not run it as a routine troubleshooting command on a working cluster. Generating a new key changes the signing identity. If the storage side still trusts an older discovery response, requests can continue to fail until the host refreshes the public key it uses.

sudo coolconfig generate-proof-key

Use that command only after confirming the key is absent or invalid and after planning how every Collabora node and WOPI host will receive the matching key information. Then follow your package or container deployment’s documented service reload procedure and re-fetch discovery from the validator’s network path.

3. Look for key mismatch across nodes or caches

A single Collabora server can work while a load-balanced deployment fails intermittently. For example, one node may have a newly generated private key while another still signs with the old key; a host with cached discovery data may trust neither consistently. This is a deployment-dependent cause, not proof that every intermittent error is caused by key rotation.

Action: fetch /hosting/discovery through the load balancer and directly from each backend, if permitted. Compare the public-key values and check that the WOPI host’s discovery cache is current. If nodes intentionally use separate keys, verify that the storage integration supports that topology; otherwise keep the proof-key configuration consistent across the cluster. Refreshing discovery should use the integration’s supported mechanism. Avoid editing a database cache or restarting unrelated services without evidence.

4. Compare the signed URL with the URL the host validates

The proof covers the absolute WOPI request URL in uppercase, as well as the token and timestamp. This makes URL rewriting relevant. A reverse proxy can change the externally visible hostname, scheme, port, path, or escaping. If Collabora signs a request for one URL but the WOPI host reconstructs a different URL for verification, a correct signature can appear invalid.

Action: correlate one failed request at the proxy and application layers. Compare the scheme, hostname, explicit port, path, and encoded characters seen by the validator with the URL used in the proof-validation code. Check forwarded-host and forwarded-proto handling only if the application relies on those headers. Preserve the real request URL; do not “fix” the issue by disabling signature checks or trusting arbitrary forwarded headers.

5. Validate timestamp and byte handling

The WOPI proof includes X-WOPI-TimeStamp. In the Microsoft WOPI specification, this header is a 64-bit integer measured in 100-nanosecond intervals since January 1, 0001, not a Unix timestamp in seconds. A custom validator that parses it as Unix seconds, drops digits, changes encoding, or assembles the signed bytes incorrectly can reject valid requests.

Clock skew is one possible cause when a host enforces a freshness window, but the exact tolerance depends on the validating implementation. Microsoft’s guidance for Microsoft 365 for the web uses a 20-minute age check; do not assume that number applies to every Collabora integration. Action: check NTP synchronization and UTC time on the Collabora and storage systems, then inspect the host’s own documented timestamp rule and parsing code.

Also check the byte-level construction if you maintain a custom WOPI host. The token is UTF-8; lengths are byte counts; the URL is the full absolute URL in uppercase; and the timestamp value must be represented exactly as specified. The public key must correspond to the private key used by the Collabora instance that sent the request.

6. Separate proof failures from allow-list and TLS errors

A WOPI host allow-list decides which storage hosts Collabora is allowed to contact. TLS validation decides whether a network peer’s certificate is trusted. Proof validation checks the signature on a WOPI request. These controls are related to secure integration, but they are not interchangeable. Adding a host to an allow-list will not repair a signature mismatch; turning off TLS checks will not correct a stale public proof key.

For Nextcloud deployments, the official troubleshooting guide recommends checking the required HTTP(S) paths in both directions, reviewing Nextcloud and Collabora logs, and confirming WOPI host allow-list entries for allow-list warnings. Action: follow the error category in the log. Test the discovery endpoint and network reachability separately from the proof validator. Do not broaden an allow-list to * as a workaround.

Safe recovery sequence

1. Capture the exact failing request time and identify which service logged proof validation failure.
2. Check Collabora logs for missing-key warnings; inspect the discovery XML from the WOPI host’s network path.
3. Compare the public key in discovery with the private key and node configuration used to sign the request.
4. Check load-balancer consistency, discovery caching, and any recent key, hostname, proxy, or TLS changes.
5. Compare the signed request URL and timestamp handling without exposing tokens or proof headers.
6. Retest with one document and confirm the same request succeeds in the host logs before restoring normal traffic.

If the failure remains, collect sanitized logs from both ends, Collabora and storage versions, deployment type, whether one or multiple nodes are involved, discovery XML with secrets removed, and the proxy route for the failing request. Share this with the relevant vendor or integration maintainers. The exact error string alone does not establish whether the cause is stale discovery, URL canonicalization, a clock issue, or a custom validator bug; the request-level evidence determines which path to pursue.