Apple PlatformIssue Guide
#005 FairPlay Open

SDK 26 rejects SPC when certificate-bundle credentials are mismatched or unreadable

AvfoundationApple forumIosGuidelineApple confirmedFairplayDrmTvosRoot cause known
GitHub source

Apple confirmed. This page is generated from GitHub Issue #5; GitHub remains the canonical authoring and discussion source.

Source#

Apple Developer Forums: https://developer.apple.com/forums/thread/840608

Problem#

A FairPlay Streaming Server SDK 26 deployment returns:

create-ckc status = -42605
invalidCertificateErr

The certificate endpoint itself appears healthy and the SDK sample vectors succeed, which can make this look like a generic CKC-generation failure.

Apple Security Engineering clarified that -42605 means the incoming SPC was generated with a certificate for which the SDK cannot resolve the matching credential set — specifically the corresponding private key(s) or provisioning data.

The reported deployment later found an actual certificate-deployment mismatch. After correcting it, CKC generation still failed because the SDK could not load the private key material correctly: encrypted PEM produced a decoding failure, while the decrypted PEM hit a runtime permission error.

Evidence level#

Apple confirmed.

Apple Security Engineer explicitly described the meaning of -42605 and the required relationship between the SPC certificate bundle, RSA-1024 private key, RSA-2048 private key, and provisioning data.

The later forum response also states that SDK private-key files should be unencrypted PEM/DER, and that the SDK does not decrypt an encrypted private key before parsing it.

Root-cause model#

Treat FairPlay SDK 26 credential loading as an identity-resolution pipeline:

certificate returned to client
        ↓
client generates SPC with certificate bundle A
        ↓
KSM receives SPC(A)
        ↓
resolve credential entry for A
        ├─ certificate bundle
        ├─ matching RSA-1024 private key
        ├─ matching RSA-2048 private key
        └─ provisioning data created with the same bundle
        ↓
load credential files at runtime
        ↓
continue CKC generation

There are therefore at least two distinct failure boundaries that can look like one "certificate problem":

A. identity mismatch
   SPC certificate ≠ configured credential set

B. credential-load failure
   correct file configured, but SDK cannot parse/read it

Do not combine these into one diagnosis.

Investigation#

1. Prove the SPC certificate identity#

Determine the exact certificate bytes supplied to the client when it generates the SPC.

Do not infer this from the file name served by /fairplay_cert.

Record a stable fingerprint for the certificate bundle used by the client and compare it with the bundle represented by the SDK configuration.

2. Verify the credential set as one unit#

For the selected SDK credential entry, verify:

certificate bundle identity
RSA-1024 private-key identity
RSA-2048 private-key identity
provisioning-data provenance

Apple's FairPlay debugging guidance already recommends proving certificate/private-key correspondence rather than trusting deployment paths or names.

For the legacy single-certificate case, the certificate and private-key modulus can be compared with OpenSSL. With SDK 26 certificate bundles, perform the equivalent validation for each key represented by the bundle.

3. Separate configuration from file loading#

Once the identities match, verify that the SDK process can actually load the credential files.

The forum case exposed two different states:

encrypted PEM
→ parsing/decoding failure

unencrypted PEM
→ permission denied

These are not certificate mismatches.

The first means the configured file format is incompatible with the SDK loader path. The second means the correct runtime process cannot read the file.

Check effective runtime user/group, file ownership, mode, parent-directory traversal permissions, container/SELinux policy where applicable, and the exact path visible to the service process.

4. Do not debug CKC business logic before credentials pass#

If credential resolution or loading fails, changing title/key lookup, CKC policy, lease rules, or client playback code is premature.

The debugging order should be:

SPC provenance
→ credential-set identity
→ credential file readability
→ SDK parses credentials
→ CKC generation
→ content-key lookup / policy
→ client playback

Verification matrix#

Use controlled A/B inputs:

A. SDK test SPC + SDK test credentials
   expected: success

B. production/client SPC + deliberately mismatched credential entry
   expected: -42605

C. production/client SPC + matching bundle, encrypted private key
   expected: credential parsing failure

D. production/client SPC + matching bundle, unencrypted private key but unreadable permissions
   expected: permission/read failure

E. production/client SPC + matching/readable credential set
   expected: progress beyond credential resolution

The purpose is to move the failure boundary deterministically instead of changing several deployment variables at once.

Solution / Guideline#

For FairPlay Streaming Server SDK 26:

  • Treat the certificate bundle, RSA-1024 key, RSA-2048 key, and provisioning data as one credential set.
  • Ensure the SPC was generated with the same certificate bundle represented by that configured entry.
  • Keep the private-key files in the format the SDK expects; based on the forum guidance, do not rely on the SDK to decrypt passphrase-protected private-key files before parsing.
  • Verify runtime read permissions separately from credential identity.
  • Do not treat "certificate endpoint returns 200" as proof that the KSM owns the matching private keys/provisioning data.

Engineering rule#

FairPlay certificate debugging is an identity-and-runtime-access problem, not a file-presence problem.

A directory containing:

fps_certificate.bin
priv_key_1024.pem
priv_key_2048.pem
provisioning_data.bin

does not prove that the four artifacts form a valid credential set or that the SDK process can read them.

Prove this chain instead:

SPC certificate identity
        ==
configured certificate-bundle identity
        ↕
matching private keys
        ↕
matching provisioning data
        ↓
runtime-readable files

The first broken transition is the root-cause boundary.

References#