Skip to main content

Rotation and validation checklist

Use this before a renewal or configuration change. Separate preparing a certificate, changing Apple-side state and proving that the consuming service works.

1. Confirm the target

  • Record the Apple Developer team, Merchant ID, certificate type, environment and affected apps or hostnames.
  • Compare certificate fingerprint, expiry and status with Apple's record and the backend or PSP actually using it. Do not rely on a filename or display name alone.
  • Assign an operator and consumer owner; schedule the handoff before expiry or a code freeze. Apple recommends renewing certificates at least 30 days early.

2. Check files and custody

  • CSR: the public request generated by the party that holds the new private key. The key stays with that party.
  • .cer: the signed certificate, not the private key. Downloading it does not recover a lost key.
  • .p12: may contain the certificate and private key. Treat it and its password as secrets; use an approved secret store and controlled handoff.
  • App Store Connect .p8: an API authentication key, not a substitute for the PP decryption key or MI server identity.

Keep private material and passwords out of repositories, browser/mobile bundles, URLs, logs and support messages.

3. Choose the correct rollout

  • PP: prepare the decrypting backend or PSP before irreversible activation. Retain the previous decryption key for tokens arriving during propagation; you cannot reactivate the old certificate.
  • MI: create and test the new server identity, switch consumers, then revoke the retired identity.
  • Domains: publish the current file for each hostname, verify with Apple and check again after HTTPS/CDN changes.

In AppsCert, review the available operation and its permissions before proceeding. A dry run or plan is preparation, not Apple-side execution. If the action is blocked or unsupported for the account, stop and use the supported operator/provider procedure rather than a legacy endpoint.

4. Verify the consumer

  1. Check the final certificate or domain status in Apple Developer and confirm the intended identity is loaded by every relevant consumer.
  2. For web changes, request a fresh merchant session on the actual affected hostname. For PP, have the backend or PSP confirm token decryption with the correct key.
  3. Run the approved checkout test in the intended environment. Merchant validation alone does not prove payment authorization or settlement; a sandbox result does not prove production acceptance.
  4. Record the result, time, certificate fingerprint and consumer confirmation without secrets. If anything fails, pause further destructive changes and coordinate recovery with the consumer owner.

For an inventory walkthrough, see Review an expiring certificate. The renewal rules above follow Apple's certificate update guidance.

c3209c7