I've just heard from iTC that this is a known issue and intentional. The issue will affect any application which implemented the legacy iAP_ReceiptValidation code defined in the "VerificationController" class. The purpose of this code was to support iOS 5.1 and earlier iAP apps to address an underlying vulnerability in iOS 6. The VerificationController class was implemented and documented as a temporary receipt validation solution. It was never designed as a general purpose receipt validation solution.
For those that are interested in this legacy doc, I've placed a reference at the end of my response. The issue here is that solution locally validates the Apple signature that is a part of the transactionReceipt. This works so long at the same certificate is used to sign the transactionReceipt. Yesterday, May 16, 2016, the certificate was changed. The signature in the transactionReceipt now fails verification with the hardcoded signature built into the app.
The recommended solution had been to update the app for post iOS 5.1, to forward the base64 encoded receipt to a trusted server for processing with the Apple Receipt Validation server. Many of you have noted that transactionReceipt has long since been marked as deprecated in favor of the applicationReceipt pointed to by
[[NSBundle mainBundle] appStoreReceiptURL].
To my knowledge, receipt validation of the transactionReceipt can still be performed.
The solution for those apps experiencing this issue is to follow the guidelines presented in the Receipt Validation Program Guide
<https://developer.apple.com/library/ios/releasenotes/General/ValidateAppStoreReceipt/Introduction.html#//apple_ref/doc/uid/TP40010573-CH105-SW1>
The link to the legacy iAP Receipt Validation for iOS 5.1 and earlier doc -
<https://developer.apple.com/legacy/library/releasenotes/StoreKit/IAP_ReceiptValidation/index.html>
rich kubota - rkubota@apple.com
developer technical support CoreOS/Hardware/MFI