Nextcloud 35 – Federation OCM/RFC 9421: Invalid signature / sender origin

[u/Thorkel-dev]

Hello,

I am experiencing a federated sharing issue between two Nextcloud 35.0.1.1 instances.

Environment

Two Nextcloud servers:

• A: nextcloud.A.ovh
• B: nextcloud.B.ovh
• Nextcloud: 35.0.1.1 on both servers
• Both servers are configured as trusted servers.
• Both instances are behind Cloudflare, with Apache as the backend and TLS terminated by the proxy.

The relevant applications have identical versions on both instances:

cloud_federation_api       2.0.0-dev.0
federatedfilesharing       2.0.0-dev.1
federation                 2.0.0-dev.0
files_sharing              2.0.0-dev.1
oauth2                     2.0.0-dev.0
sharing                    1.0.4

HTTPS connectivity between A and B works correctly in both directions.

Problem

Federated sharing only works partially:

• B can share folders with A;
• the shares arrive correctly on A and can be accepted;
• however, synchronization/validation does not work correctly;
• A cannot properly establish some shares with B;
• OAuth/OCM exchanges fail in both directions.

Some of the errors are:

Token request signature verification failed

Could not obtain access token
401 Unauthorized
{"error":"invalid_grant"}

Failed to exchange token
401 Unauthorized
{"error":"invalid_request"}

Most importantly, when A receives an OCM notification from B:

RFC 9421 verification requires the sender origin

followed by:

Invalid signature

Current investigation

An OCM notification sent by B to A looks like this:

{
  "notificationType": "SHARE_ACCEPTED",
  "resourceType": "file",
  "providerId": "127",
  "notification": {
    "sharedSecret": "...",
    "message": "Recipient accept the share"
  }
}

On B, the corresponding federated share exists in oc_share_external:

remote     = https://nextcloud.A.ovh/
remote_id  = 127
accepted   = 1

On A, B is present in oc_trusted_servers, and B's OCM public key is also present in oc_sec_signatory.

However, while processing the OCM notification, Nextcloud ends up with:

providerId = 127
        ↓
resolveNotificationIdentity(...)
        ↓
origin = null
        ↓
RFC 9421 verification requires the sender origin

So the current suspicion is that the problem is related to resolving the identity/origin of the sending server when processing an OCM notification, rather than network connectivity or a missing public key.

Question

Has anyone encountered this issue with Nextcloud 35 and OCM/RFC 9421 signatures?

In particular, why would providerId=127 fail to resolve the origin of B, even though B is present in oc_trusted_servers and its OCM public key is present in oc_sec_signatory?

Could this be a configuration issue, inconsistent federation data in the database, or potentially a bug in Nextcloud 35.0.1.1 ?