Apple Pay

Dear Lazyweb,

I'm back to trying to integrate Apple Pay into the DNA Lounge store. How does "onvalidatemerchant" work with authorize.net?

I got an Apple CSR from authorize.net and submitted that CSR to Apple. That gave me my merchant ID, "merchant.com.dnalounge.store", and the CER file "apple_pay.cer".

All of the example code says that my backend needs to retrieve a merchantSession from Apple by connecting to the "validationURL" passed to "onvalidatemerchant" by using CURLOPT_SSLCERT and/or CURLOPT_SSLKEY, but I think I don't have the private key -- only authorize.net has that, right? All I have is the CER file. So how do I get the merchantSession from Apple?

Previously.

Tags: , , , , ,

13 Responses:

  1. X says:

    Silly question, but what does the .CER file actually contain? I.e. what are the lines beginning with dashes (in the whole file)?

    What I'm after is that maybe that is also the private key.

    • jwz says:

      It's a binary file and only 1153 bytes so I'm not sure how to tell.

      • Dirk says:

        You can view the content of the .cer file using openssl of course with openssl x509 -inform der -in apple_pay.cer -noout -text

        But I'm pretty sure your assumption is correct that this file only contains the certificate and NOT the private key. But the certificate should be enough to create a TLS-Session using curl.

        • jwz says:

          It contains "Subject Public Key Info" and does not mention the word "private" so I'm guessing that means there's no private key in there.

        • Nick Lamb says:

          But the certificate should be enough to create a TLS-Session using curl.

          No. The certificate is a public document. You can't do anything with it on its own except be like "Hey, look at this public document which exists". It doesn't prove anybody's identity on its own since anybody can make copies of any certificate, and we do, all the time.

          To use the certificate with curl to make a mutually authenticated TLS connection, as Jamie describes, you need to also have the private key. During handshake, the server will ask to see your certificate, and it will ask for proof you know the associated private key. If you don't have the private key, you will be unable to provide such proof ‡ and so the server has no reason to think this is really your certificate.

          Jamie doesn't have this private key, so he cannot create a mutually authenticated TLS session, and so it can't be used for this purpose. As we see below, this is because there are other keys (and certificates) because Apple has a hammer and now all it sees are nails.

          ‡ If you use the same RSA keys for an archaic SSLv3 server it can be tricked into providing suitable proof in some cases in a difficult but practical online attack. So, never do that. Also, time to use a more modern cryptosystem grandpa.

    • Nick Lamb says:

      So, on the one hand this is a more reasonable question than it looks because PKCS#12 exists, which is a format that puts the certificate and private key in the same file (often a .p12 or .pfx). But while that's popular on Windows, it doesn't make much sense philosophically (now the file contains something that you're happy to show anybody and something no-one else must ever know, why put these together?) and is uncommon on other platforms.

      However in this case it's clearly wrong because the whole point is that Apple doesn't learn the private key. Authorize.net picks a random private key, and it gives Jamie both a proof that it knows this key (but just the proof, not the key itself) and the associated public key [in the CSR], for Jamie to show to Apple. Since Apple doesn't learn the private key, they can't very well put it in a file to give to Jamie. Therefore this file cannot possibly contain the private key.

  2. cleanslate says:

    You apparently need another key pair called "Apple Pay Merchant Identity Certificate" to authenticate against Apple's servers. This guide shows how it works for portmone's API, but authorize.net should be similar:
    ttps://docs.portmone.com.ua/docs/en/APayEng/#steps-to-integrate-apple-pay-on-website

    • jwz says:

      Thanks, I had completely missed -- multiple times -- that "Apple Pay Payment Processing Certificate" and "Apple Pay Merchant Identity Certificate" were not the same words. My brain translated both of them to "Apple Blah Blah Blah" and moved on.

      • Glaurung says:

        Another sign of Apple resting on its laurels when it comes to usability: if they'd said up front, "you need 2 certificates, they are called A and B," a lot of your frustration could have been eliminated.

        Also, "Apple Blah blah blah" is a perfectly reasonable way to parse most utterances from such a corporate giant. Your brain was doing the right thing, and it's not its fault that it was not the correct thing in this one case.

      • Eric TF Bat says:

        Replace "Apple" with "Google" and that's exactly the problem I was having with their Merchant Center last month. A maze of twisty little acronym expansions, all alike. It's a sign that the system's designers don't know what they're doing: if you can't name a thing coherently, you can't reason about it.

    • jwz says:

      Well I got it working but after all this I still don't understand why the "Apple Pay Payment Processing Certificate" exists at all, or, more importantly, how it is even referenced by anything. I don't seem to actually be using it anywhere, so why did I have to create it?

      • Nick Lamb says:

        I think in practice this is merely a way for Apple to learn which RSA public key they need to encrypt messages for sending to your Authorize.net backend (perhaps wrapped in some blob they give to you?). The CSR you got from Authorize.net has that public key inside it, along with proof that whoever made the CSR knows the private key, and presumably some claim about which Apple Blah Blah Blah ID is involved. So you signing in to Apple to upload the CSR file signifies that you want to use this backend, the CSR file tells Apple which key to use, the ID inside it confirms you didn't mix up two store fronts and give them the wrong CSR.

        So very likely the flow could end with Apple saying "Thanks, bye" after you give them a CSR, but they feel obliged to respond to a Certificate Signing Request with a Certificate. I don't know if American schools have some certificate analogous to the one I got for being able to swim ten metres when I was six but if you've framed that you should definitely print this out and frame it too because it's just as useful. Some payment backends keep up the pretense and have you send them the certificate, but I suspect they have no more use for it than you do.

      • cleanslate says:

        I'm fairly certain that the important parts of the paymentData you pass on from Apple to the bank are encrypted with the PPC. And they use individual per-Merchant-ID PPCs instead of one per bank so that they can be revoked individually (and safely load-balanced) and for additional attribution information for their fraud monitoring.

  • Previously