|
| 1 | +.. _ocm_label: |
| 2 | + |
| 3 | +============ |
| 4 | +OCM commands |
| 5 | +============ |
| 6 | + |
| 7 | +The ``ocm`` commands manage the signing keys that Nextcloud uses for Open Cloud |
| 8 | +Mesh (OCM) federation. Outbound OCM requests are signed with HTTP message |
| 9 | +signatures (`RFC 9421 <https://www.rfc-editor.org/rfc/rfc9421>`_), and the |
| 10 | +matching public keys are published as a `JSON Web Key Set (JWKS) |
| 11 | +<https://www.rfc-editor.org/rfc/rfc7517>`_ so that federated peers can verify |
| 12 | +them. |
| 13 | + |
| 14 | +These commands are part of the server core and are always available. They are |
| 15 | +used to inspect and rotate the JWKS signing keys; you do not need them for |
| 16 | +normal operation, as a key is generated automatically on the first OCM request. |
| 17 | + |
| 18 | +.. note:: |
| 19 | + |
| 20 | + For more on federation and OCM, see |
| 21 | + :doc:`configuration_files/federated_cloud_sharing_configuration`. |
| 22 | + |
| 23 | +:: |
| 24 | + |
| 25 | + ocm |
| 26 | + ocm:keys:list list JWKS-published signing keys |
| 27 | + ocm:keys:stage generate a new JWKS key and advertise it via JWKS without using it for signing yet |
| 28 | + ocm:keys:activate promote the staged JWKS key to active; the previous active key moves to retiring |
| 29 | + ocm:keys:retire delete the retiring JWKS key; signatures that referenced its kid can no longer be verified |
| 30 | + |
| 31 | + |
| 32 | +Key slots |
| 33 | +--------- |
| 34 | + |
| 35 | +The signing keys live in three slots, all of which are published in the JWKS |
| 36 | +endpoint while they are populated: |
| 37 | + |
| 38 | +* **active** — the key currently used to sign outbound OCM requests. |
| 39 | +* **pending** — a newly staged key that is advertised in the JWKS but not yet |
| 40 | + used for signing. This gives federated peers time to pick it up before it |
| 41 | + becomes active. |
| 42 | +* **retiring** — the previous active key, kept published so that signatures |
| 43 | + created with it can still be verified until it is removed. |
| 44 | + |
| 45 | +Listing keys |
| 46 | +------------ |
| 47 | + |
| 48 | +ocm\:keys\:list |
| 49 | +^^^^^^^^^^^^^^^ |
| 50 | + |
| 51 | +Show the current JWKS signing keys and the slot each one occupies:: |
| 52 | + |
| 53 | + sudo -E -u www-data php occ ocm:keys:list |
| 54 | + +------+----------+--------------------------------+ |
| 55 | + | Pool | Slot | Key ID | |
| 56 | + +------+----------+--------------------------------+ |
| 57 | + | 1 | active | ecdsa-p256-sha256-... | |
| 58 | + | 2 | pending | ecdsa-p256-sha256-... | |
| 59 | + +------+----------+--------------------------------+ |
| 60 | + |
| 61 | +If no keys exist yet, the command reports that one will be generated on the |
| 62 | +first OCM request. Use ``--output=json`` or ``--output=json_pretty`` for |
| 63 | +machine-readable output. |
| 64 | + |
| 65 | +Rotating keys |
| 66 | +------------- |
| 67 | + |
| 68 | +Key rotation is a three-step process: stage a new key, activate it, then |
| 69 | +retire the old one. Allow time between the steps so that federated peers can |
| 70 | +refresh their cached copy of your JWKS (the cache lifetime is one hour). |
| 71 | + |
| 72 | +ocm\:keys\:stage |
| 73 | +^^^^^^^^^^^^^^^^ |
| 74 | + |
| 75 | +Generate a new key into the **pending** slot. It is advertised in the JWKS but |
| 76 | +is not yet used for signing:: |
| 77 | + |
| 78 | + sudo -E -u www-data php occ ocm:keys:stage |
| 79 | + Staged new JWKS key: ecdsa-p256-sha256-... |
| 80 | + Wait for federated peers to refresh their JWKS cache before activating. |
| 81 | + |
| 82 | +An active key is required first; if none exists, one is generated |
| 83 | +automatically. The command fails if a pending key already exists — activate or |
| 84 | +retire it before staging another. |
| 85 | + |
| 86 | +ocm\:keys\:activate |
| 87 | +^^^^^^^^^^^^^^^^^^^ |
| 88 | + |
| 89 | +Promote the staged (pending) key to **active**. The previous active key moves |
| 90 | +to the **retiring** slot, where it stays published in the JWKS so that |
| 91 | +in-flight signatures can still be verified:: |
| 92 | + |
| 93 | + sudo -E -u www-data php occ ocm:keys:activate |
| 94 | + Staged key promoted to active. |
| 95 | + Run occ ocm:keys:retire once any in-flight signatures using the previous key have been verified. |
| 96 | + |
| 97 | +The command fails if there is no pending key to activate, or if the retiring |
| 98 | +slot is still occupied — retire the previous key first. |
| 99 | + |
| 100 | +ocm\:keys\:retire |
| 101 | +^^^^^^^^^^^^^^^^^ |
| 102 | + |
| 103 | +Delete the **retiring** key. Once removed, signatures that referenced its key |
| 104 | +ID can no longer be verified, so only run this after you are confident that no |
| 105 | +peer still needs it (for example, after at least one JWKS cache lifetime has |
| 106 | +passed since activation):: |
| 107 | + |
| 108 | + sudo -E -u www-data php occ ocm:keys:retire |
| 109 | + Retiring key deleted. |
| 110 | + |
| 111 | +The command fails if there is no retiring key to remove. |
0 commit comments