We are updating the new certificates in our Non-Production environment.
The steps we followed,
- Created and downloaded a new Merchant Identity certificate, converted and updated on our servers. Now we have a new certificate and an old certificate on the portal, both have valid expiration dates.
- Created and downloaded a new Payment Processing certificate, converted and updated in our backed system (vault). Now we have a new certificate and an old certificate, both have valid expiration dates. However, activated the new Payment Processing certificate as it was showing only the previous one as Active, and Activate option was showing against the new one if we would like to do so. Doing this has automatically revoked the old certificate.
We have then tried testing the Apple Pay payments. Result: We can see that the Merchant Validation API is going through successfully and returns the session object. But when the payment token is getting decrypted with the new Payment Processing certificate, private key, and ephemeral public key, the token is not getting decrypted. Instead, it was giving the error - javax.crypto.AEADBadTagException: mac check in GCM failed.
Even after a lot of troubleshooting and repeating the certificate update steps multiple times, we couldn’t find any clue. Then we tried the below few steps as part of further analysis.
- We tried to decrypt the new payment token generated with the previous Payment Processing certificate and key which we reinstated in our backend. The decryption was successful. This was baffling as to why the new payment token which was generated as part of the new Merchant Identity certificate would get decrypted with the old Payment Processing certificate and key.
- Then as we know that there were 2 Merchant Identity certificates active on the Apple portal, we have revoked the previous Merchant Identity certificate as well on the portal assuming the Merchant Validation API call would have been processed with the previous Merchant Identity certificate at Apple. Now when we tried the Apple Pay payments again with the new certificates all-around, the token decryption and hence the payment processing went through successfully.
Hence, the conclusion was that after creating and updating new certificates, the new Apple Pay payments are successful only when both the previous Merchant Identity and Payment Processing certificates are revoked. Is this a valid approach or are we missing something?
In our Production environment, we want to rotate the certificates without revoking the previous ones. Kindly let us know how we can achieve the same. Prompt replies are appreciated as expiry is nearing soon.
Hi @raheem5025,
Most merchants rotate/roll their certificates from an expiring one to a newly created one without interruption. Essentially, merchants or Payment Service Providers (PSPs) should set up the keys, upload the Certificate Signing Request (CSR) and generate the certificates, import then new cert into their key store. Once they are ready, they can activate the new certs in the Apple Developer account to have Apple start encrypting with new certs.
Please ensure both key-pairs (private keys) remain active on their side for a period of time to cover the transition, sometimes the new keys/certs take a short while to propagate across Apple's infrastructure.
Its also recommended to use the publicKeyHash (part of the Apple Pay token payload to recognize which public key was used to encrypt—you can then find the corresponding key pair on your end to ensure the decryption is attempted using the correct private key.
Alternatively, it may also be possible to create a new CSR from the same key pair, therefore the private key never actually changes. A merchant can upload the new CSR, generate a new certificate and then "Activate" the new cert. Because the keys have not actually changed, the existing private key should continue to work.
Cheers,
Paris X Pinkney | WWDR | DTS Engineer
