HTTP Signatures in Misskey ActivityPub#

Misskey uses HTTP Signatures to authenticate outbound and inbound ActivityPub requests. All signing primitives live in ApRequestService.ts under packages/backend/src/core/activitypub/. The @peertube/http-signature library handles parsing and verification on the inbound side 1.

Signing Outbound Requests#

The static class ApRequestCreator exposes two signing methods used throughout the stack:

• createSignedPost — signs POST requests (activity delivery). Signed headers: (request-target), date, host, digest 2.
• createSignedGet — signs GET requests (AP object fetching). Signed headers: (request-target), date, host 3.

Both delegate to the private #signToRequest method, which:

1. Builds the signing string via #genSigningString.
2. Signs it with RSA-SHA256 using the slacc library's RsaKeyPair 4.
3. Produces a Signature header of the form:
   keyId="…",algorithm="rsa-sha256",headers="…",signature="…" 5.

(request-target) Construction#

#genSigningString builds the signing string by iterating over the included headers. For the special (request-target) pseudo-header, it emits (request-target): <method_lowercase> <pathname> — e.g., (request-target): post /inbox — where the pathname comes from new URL(request.url).pathname 6. All other header names are lower-cased and their values taken verbatim from the request object. The lines are joined with \n.

Digest Header#

For POST requests, a Digest header is computed as SHA-256=<base64(sha256(body))> via createDigest. If not pre-computed by the caller, createSignedPost generates it automatically 7.

Key Identity#

The keyId is always {instanceUrl}/users/{userId}#main-key 8. The corresponding RSA keypair is fetched—with Redis + in-memory caching—from UserKeypairService.getUserKeypair().

The injectable ApRequestService wraps ApRequestCreator with NestJS DI, providing signedPost() and signedGet() methods that look up the user's keypair and execute the HTTP request via HttpRequestService.

Verifying Inbound Requests#

Verification is split across two stages:

Stage 1 — HTTP layer (ActivityPubServerService.inbox()):

• Parses the Signature header with httpSignature.parseRequest(), requiring (request-target), host, and date 1.
• Rejects requests where host is absent or doesn't match the configured hostname 9.
• Requires a digest header and validates SHA-256=<hash> against the raw request body 10.
• On success, enqueues the activity body + parsed signature for async processing 11.

Stage 2 — Queue layer (InboxProcessorService.process()):

• Resolves the signer's public key via apDbResolverService.getAuthUserFromKeyId(signature.keyId) 12.
• Calls httpSignature.verifySignature(signature, authUser.key.keyPem) 13.
• Also asserts that authUser.user.uri === activity.actor — the signing key owner must be the declared actor 14.

LD-Signature Fallback#

If HTTP Signature verification fails but the activity contains an embedded signature object, Misskey falls back to Linked Data Signatures (RsaSignature2017) 15. Verification is handled by JsonLdService.verifyRsaSignature2017(), which JSON-LD-canonicalizes the activity before verifying. Outbound LD signatures are attached by ApRendererService.attachLdSignature().

Key Files#