Expired intermediate certificates in StoreKit 2 JWS

We send StoreKit 2 signed transactions to our server for validation and processing. As part of this process, as recommended by Apple, we validate the certificate chain against the "Apple Root CA - G3 Root" certificate found here: https://www.apple.com/certificateauthority/

As of 24th September we started noticing this validation erroring because of expired certificates in the JWT. On further investigation we see the first cert in the chain, with the common name "Prod ECC Mac App Store and iTunes Store Receipt Signing", appears to have expired at "Sep 24 02:50:33 2023 GMT"

I checked and calling the App Store API at "inApps/v1/subscriptions/" with the same transaction id also returns the subscription with the same expired certificate in the chain so I am confident that this is a genuine transaction issued by Apple.

For now we have been forced to disable validating the expiry date of intermediate certificates to work around this. I'm however really surprised I haven't found anyone else discussing this or any documentation around how to handle this situation.

Is it expected that the App Store JWS would contain an expired certificate and what is the guidance on how to proceed in this situation?

Up vote post of binaryalchemy Down vote post of binaryalchemy
574 views
Posted by
binaryalchemy
Reply
Add a Comment

Replies

Are these JWSs generated recently? I just called the inApps/v1/subscriptions endpoint and received certificates expiring in 2025.

Posted by
App Store Commerce Engineer
Up vote reply of App Store Commerce Engineer Down vote reply of App Store Commerce Engineer

  • We have also encountered the same issue recently, and checking the SignedDate is in June

    —
    yt-w
Add a Comment

checking the signedDate field I can see that the specific example transaction I am looking at was signed 2023-09-12. So I guess technically the certificate was valid when it was signed. I would need some more time to investigate signed dates of other transactions that were failing.

The problem is that this is for an annual subscription that is valid for 10 more months so the server may very likely re-check the transaction again if it is sent up from the client. I just assumed that either transactions would get re-signed or that the certificate expiry would be far enough in the future that this wouldn't be an issue.

If I am understanding correctly it seems like we need to be checking that the signedDate is within the window of certificate validity rather than the current date. Does that sound right?

Posted by
binaryalchemy
Up vote reply of binaryalchemy Down vote reply of binaryalchemy
Add a Comment