Search code examples
phpioscurlin-app-purchasesandbox

In App Purchase (Sandbox) - Receipt Validation Fails Because of curl / SSL

I have noticed that my server-side receipt validation code is failing only for the sandbox (the live version of my app in the store works fine, but on Xcode, where I am testing the next version, receipt validation always fails).

I tracked the problem to the php/curl code where I contact the iTunes server (https://sandbox.itunes.apple.com/verifyReceipt), and I get this error from curl:

SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:func(144):reason(134)

I wonder if this has anything to do with the russian guy and his hack... But it only happens with my sandbox code. The live version seems to be working...

Any clues?

Perhaps I should use the 'live' iTunes server for both sandbox and live, as detailed here? in app purchase, production receipt validation now validating sandbox purchases?

(Wasn't aware of this change. Is it still OK?)

EDIT I modified my sandbox-php code to use the LIVE iTunes server (URL: https://buy.itunes.apple.com/verifyReceipt), and test-user purchases/repurchases are working now. I am still puzzled... Has the sandbox server been deprecated? Does it identify itself with an SSL certificate different than the live environment, which certificate has been revoked?

Solution

  • Looks like Apple recently reupped the SSL cert for Sandbox and it is signed correctly with the subject alternate name domain sandbox.itunes.apple.com. but didn't sign it with the correct URL (or just used the one from Live and not bothered with Sandbox). They instead signed it with buy.itunes.apple.com which broke any cURL requests (our server had the same problem). As a workaround for now, we have used the option:

    if ($isSandbox) curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);

    This turns off SSL verification, so use with caution as it could lead to man-in-the-middle attacks. I don't think this is a huge deal on Sandbox since it is test users in a test environment.

    Edit:

    Actually, Apple pointed out that the CA cert bundle with a default cURL install prior to 7.18.0 is severely outdated. http://curl.haxx.se/docs/sslcerts.html

    We may have had a server update recently that broke our cURL installation, but I'm not our Sys Admin so I really don't know for sure. But take a look at the link as that includes the workaround I mentioned above (#1), and a few other options, including updating the CA cert bundle.

    Edit:

    I wanted to add another side-note here. It seems as though there was a bug fix in cURL version 7.19.7 that dealt with Subject Alternative Names.

    • libcurl-OpenSSL failed to verify some certs with Subject Alternative Name

    So this could in fact be partially Apple, and partially cURL. Apple's certificate renewal with the usage of the SAN possibly broke anything still on any version older than 7.19.7. We are still testing as to whether this is the case on our server.

    Edit:

    We found out that the issue was not the version of cURL we were using, but it was with the CA cert pem file we needed cURL to point to. It is #2 via the cURL link above, but in PHP it looks like this:

    if ($isSandbox) curl_setopt($ch, CURLOPT_CAINFO, '/etc/ssl/certs/cacert.pem');

    You can grab the latest CA cert pem file from http://curl.haxx.se/docs/caextract.html