Last updated: March 15, 2026

How Apple certificate chain verification works for App Store Server Notifications

Apple's webhook security can feel confusing at first. You see words like x5c, certificate chain, root certificate, and JWS signature, and it's hard to know what actually matters.

Here's the short answer: Apple sends a signed payload, and your server needs to prove two things before trusting it. First, the signing certificate needs to chain up to a trusted Apple root. Second, the payload itself needs to match the signature.

What Apple actually sends

Apple's App Store Server Notifications V2 use a field called signedPayload. That payload is a compact JWS, which means it has:

• a header
• a payload
• a signature

Inside the JWS header, Apple also sends an x5c field. That field contains the certificate chain for the key that signed the payload.

The three kinds of certificates

You can think of the chain like a trust ladder.

Leaf certificate

The leaf certificate is the first certificate in Apple's x5c list. It contains the public key that verifies the JWS signature.

Intermediate certificate

Intermediate certificates sit in the middle of the chain. They help prove that the leaf certificate was issued by Apple's certificate hierarchy.

Root certificate

The root certificate is the trust anchor. This is the certificate your system already trusts before the webhook arrives. In SubTru, Apple root certificates are loaded from a local trust bundle at startup.

What the certificate chain proves

The chain does not tell you whether the payload contents are correct. It tells you whether the signing certificate can be trusted as part of Apple's certificate hierarchy.

In practical terms, your server checks whether:

1. the leaf certificate chains to an intermediate
2. the intermediate chains to a trusted Apple root
3. the chain is valid for the right time and policy

You still need both checks. The chain says the signing certificate is trusted. The signature says this exact payload was signed by the matching private key.

How SubTru verifies the Apple chain

SubTru follows a strict model for Apple trust.

1. We read the leaf and intermediate certificates from Apple's x5c header.
2. We load trusted Apple root certificates from a local trust bundle.
3. We build the certificate chain with .NET CustomRootTrust.
4. We disable runtime certificate downloads during webhook handling.
5. We verify the JWS signature with the leaf certificate's public key.
6. We still check app identity fields like bundleId, environment, and appAppleId.

This means the trust decision comes from the Apple roots your API already trusts locally, not from whatever root certificate happens to show up inside the webhook payload.

Why local Apple roots matter

This is one of the most important parts of the design.

Apple publishes its root certificates through Apple PKI. SubTru loads those roots from a local directory at startup and uses them as the only trust anchors for Apple signed data.

That is safer than trusting a root certificate just because it was sent in the webhook. It also makes operations simpler, because trust updates happen through a reviewed trust-bundle update instead of a live network fetch during request handling.

Why runtime certificate downloads are disabled

During webhook processing, SubTru does not let .NET go out to the network to fetch missing certificates.

That keeps verification deterministic and easier to reason about. The API uses the certificates Apple sent in x5c plus the trusted Apple roots it already loaded locally. It does not depend on a last-second network call to finish the chain.

What happens if verification fails

If the chain does not build, the signature does not match, or the app identity checks fail, SubTru does not treat the payload as trusted business data.

In plain English, a webhook only changes subscription state after it passes the full trust check.

The simple summary

Here is the easiest way to remember it:

• Apple sends the signer certificate and intermediates in x5c
• your API supplies the Apple roots it already trusts
• .NET builds a chain from the signer to a trusted Apple root
• then the signer's public key verifies the JWS signature

If both checks succeed, you can trust the webhook enough to move on to app identity checks and subscription state handling.