CODEWITHSUNDEEP
iosjwt
Tim
Tim

Reputation: 81

How to test Apple app store notifications in jwt debugger

I am implementing server to server communication for Apple app store notifications as described here

https://developer.apple.com/documentation/appstoreservernotifications/

I can receive a JWT and obtain the responseBodyV2 object.

https://developer.apple.com/documentation/appstoreservernotifications/responsebodyv2

I would like to test the JWT in the debugger at

https://jwt.io/#debugger-io

I paste the signed payload into the left hand window in the debugger. The debugger decodes the payload, correctly identifies the algorithm as ES256, displays the x5c certificate chain and the payload data. In the "Verify Signature" panel the debugger inserts the first certificate in the certificate chain in the public key text box and leaves the private key text box empty. It also displays the message "Signature verified".

I have two questions.

  1. How can the debugger successfully verify the signature when I haven't entered the shared secret from our Apple account? (I presume this should be entered in the private key text box).

  2. Should I use the x5c certificate chain and if so how?

Upvotes: 1

Views: 833

Answers (1)

Chuck Batson
Chuck Batson

Reputation: 2744

JWS with 'x5c' uses an X509 certificate chain to establish trust, similar to web browsers.

From RFC 7517 section 4.1.6, "x5c" (X.509 Certificate Chain) Header Parameter:

The "x5c" (X.509 certificate chain) Header Parameter contains the X.509 public key certificate or certificate chain [RFC5280] corresponding to the key used to digitally sign the JWS. The certificate or certificate chain is represented as a JSON array of certificate value strings. Each string in the array is a base64-encoded (Section 4 of [RFC4648] -- not base64url-encoded) DER [ITU.X690.2008] PKIX certificate value. The certificate containing the public key corresponding to the key used to digitally sign the JWS MUST be the first certificate. This MAY be followed by additional certificates, with each subsequent certificate being the one used to certify the previous one. The recipient MUST validate the certificate chain according to RFC 5280 [RFC5280] and consider the certificate or certificate chain to be invalid if any validation failure occurs. Use of this Header Parameter is OPTIONAL.

(Emphasis added.)

Basically, the JWS is signed by the first certificate, and the JWS's signature must be validated using this certificate. Then, each certificate is in turn signed by the next, establishing a chain of trust that must ultimately lead to a root CA known to you that you trust. The entire chain of signatures must be validated and terminate in a known certificate you trust in order for the JWS to be considered valid.

You can read more about certificate chain validation in RFC 5280 section 6, Certification Path Validation.

Note that there's been no mention of the Apple shared secret. That's because the shared secret is used for calls to Apple's verifyReceipt endpoint, and has nothing to do with JWS signature validation.

Upvotes: 0

Related Questions