Skip to content

Decryption Failed

URI: https://docs.ankatech.co/errors/decryption-failed
HTTP Status: 422 Unprocessable Entity

When You See This

Your PKCS#7/CMS file is valid and supported and a matching private key was located, but the conversion engine could not decrypt the protected content. This is raised during PKCS#7 → JOSE conversion (POST /api/v3/migration/convert-pkcs7-to-jose and POST /api/v3/migration/stream/convert-pkcs7-to-jose) when the supplied recipient private key cannot decrypt the PKCS#7 EnvelopedData / SignedAndEnvelopedData content.

In other words: the key was found, but it does not actually unwrap this ciphertext — typically because the wrong recipient key was selected, or the PKCS#7 ciphertext is corrupted or truncated.

Common Causes

  • Wrong recipient key selected – The provided decryptionKid resolves to a key that does not match the recipient this message was encrypted for

  • Corrupted ciphertext – The PKCS#7 EnvelopedData content was altered or damaged in transit or storage

  • Truncated file – The PKCS#7 file is incomplete (cut off during upload, copy, or export)

No Cryptographic Details Disclosed

The detail field is a curated, generic message that deliberately discloses no cryptographic internals — it does not reveal which step failed, the algorithm, padding state, or any key material. This is an intentional OWASP no-information-disclosure design choice: a precise error would create a decryption oracle that an attacker could exploit to recover plaintext. Both "wrong key" and "corrupted ciphertext" therefore surface as the same opaque message.

Response Example

{
  "type": "https://docs.ankatech.co/errors/decryption-failed",
  "title": "Decryption Failed",
  "status": 422,
  "detail": "Decryption failed: the supplied key could not decrypt the PKCS#7 content.",
  "instance": "/api/v3/migration/convert-pkcs7-to-jose",
  "correlationId": "550e8400-e29b-41d4-a716-446655440000",
  "timestamp": 1738117563
}

Content-Type: application/problem+json — the response follows RFC 7807 Problem Details.

How to Resolve

Step 1: Confirm the Recipient Metadata

Re-run the analyze endpoint to see which recipient the message was encrypted for:

POST /api/v3/migration/analyze-pkcs7
Content-Type: application/json

{
  "pkcs7Data": "<base64-encoded-pkcs7>",
  "validateCertificates": false
}

The response shows the recipient's issuerDN and serialNumber — these identify the exact private key required for decryption.

Step 2: Verify the Correct Private Key Is Imported

Ensure the imported private key matches the PKCS#7 recipient's issuer DN and serial number:

GET /api/v3/migration/keys/{kid}

The certificate metadata returned must match the recipient identified in Step 1. If it does not match, select (or import) the correct key.

Step 3: Re-Run the Conversion

Retry with the decryptionKid that resolves to the matching recipient key:

POST /api/v3/migration/convert-pkcs7-to-jose
Content-Type: application/json

{
  "pkcs7Data": "<base64-encoded-pkcs7>",
  "decryptionKid": "my-recipient-key",
  "serialization": "AUTO",
  "targetFormat": "AUTO"
}

Step 4: Rule Out Corruption

If the correct key is confirmed and decryption still fails, the PKCS#7 content is likely damaged:

  • Re-export or re-download the PKCS#7 file from the source system
  • Confirm the file is complete and was not truncated during transfer
  • Compare the file size against the original to detect truncation
  • Missing Private Key - The required private key was never imported (the recipient could not be matched at all) → 422 missing-private-key
  • Resource Not Found - The supplied kid or certificate identifier is not resolvable → 404
  • Unsupported PKCS#7 Format - The PKCS#7 structure is valid but uses a feature not yet supported (e.g., multiple recipients)

Need Help?

  • Use POST /api/v3/migration/analyze-pkcs7 to confirm the recipient metadata before retrying
  • If the correct key is imported and the file is intact but conversion still fails, contact support with the correlationId from the error response