Apple Wallet Pass Certificates Explained: Pass Type ID, Signing and Renewal

Every Apple Wallet pass is signed with a certificate tied to a Pass Type ID that you register in your Apple Developer account. The signature proves the pass came from you and has not been altered, and the same certificate lets you send updates to passes already installed. Certificates expire, so renewing before the expiry date is a routine job: a lapsed certificate does not remove passes from customers' phones, but you can no longer sign new passes or update existing ones. This guide explains each piece (Pass Type ID, certificate, signature, WWDR intermediate), how to renew safely, and the alternative of letting a platform hold the certificate for you.

The pieces and how they fit

The pass.json inside each pass repeats two of these values: passTypeIdentifier and teamIdentifier. They must match the certificate you sign with, or Wallet rejects the pass (Apple: Building a pass).

What a Pass Type ID is

A Pass Type ID names a family of passes: for example one for your loyalty card and another for your gift cards. Each pass you issue has a unique serialNumber within that Pass Type ID. The identifier is permanent once registered, and every pass ever issued under it carries it, so choose a sensible name before you issue anything. The Pass Type ID is also the topic for the push messages that tell a device to refresh a pass (see how updates and push notifications work).

How a pass gets signed

A .pkpass file is a zip archive. Inside are pass.json, the images, a manifest.json and a signature file. Signing works like this:

1. Hash every file. manifest.json lists each file in the pass with its SHA-1 hash.
2. Sign the manifest. Using your Pass Type ID certificate's private key, you create a detached PKCS #7 signature of manifest.json. The signature also includes the WWDR intermediate certificate so Wallet can verify the chain.
3. Zip and serve. The signature is saved as signature, the archive is zipped, and the file is served as application/vnd.apple.pkpass.

When the customer adds the pass, Wallet recomputes the hashes, checks the signature and checks the chain up to Apple's root. If any file was altered, a hash is missing, or the certificate is expired or mismatched, the pass will not add.

You can inspect the structure and the manifest hashes of any .pkpass with the free pkpass validator. It runs in your browser. It cannot verify the signature itself, so a failed add on a real device is the final test.

Creating the certificate, step by step

Apple's own help pages cover the exact screens (Create a certificate signing request). In outline:

1. Enrol in the Apple Developer Program.
2. In Certificates, Identifiers and Profiles, register a Pass Type ID.
3. Generate a certificate signing request (CSR) on your Mac with Keychain Access, or with OpenSSL on a server. Keep the private key. Apple never sees it, and without it the certificate is useless.
4. Upload the CSR against your Pass Type ID, download the certificate, and install it alongside the private key.
5. Export the certificate and key in the format your signing library expects (often a .p12 or PEM files).
6. Download the current WWDR intermediate certificate from Apple's certificate authority page.

Treat the exported key like a password to your brand: anyone who holds it can issue passes that look like yours. Keep it in a secret store, not in the code repository.

Expiry: what actually happens

Pass Type ID certificates are issued for a limited period; at the time of writing, platforms that document this describe it as one year, and the expiry date is shown in your Apple Developer account. Check your own account rather than relying on a number in an article.

When the certificate expires:

• Passes already on customers' phones keep working. They still display and still scan.
• You cannot sign new passes with the expired certificate.
• You cannot update installed passes, because updates are new signed passes, and the push uses the same certificate.

So an expired certificate does not produce a dramatic failure. It produces silence: new customers get an error when they add a pass, and existing customers stop seeing balance changes. That is why it often goes unnoticed for days.

The WWDR intermediate also changes from time to time. If signing starts failing right after a change on Apple's side, replace your copy with the current one from the certificate authority page.

Renewal without breaking anything

1. Put the expiry in a calendar, with a reminder at least a month ahead, and name an owner. Certificate renewals are the classic "the person who set it up has left" failure.
2. Create a new certificate for the same Pass Type ID. Do not register a new identifier: passes already installed carry the old one and would be orphaned.
3. Install the new certificate and key in your signing service, and keep the old one available until you have confirmed the new one works.
4. Sign a test pass, add it to a device and run a test update.
5. Retire the old certificate only after live passes and updates are confirmed working.

Three ways to handle certificates

On Shakewell Wallet, passes are signed with Shakewell's own certificate and renewed for you, so you do not need an Apple Developer account of your own; using your own certificate is a separate option that is not part of standard plans (Apple Wallet setup, help: do I need an Apple Developer account?). If you are comparing platforms, ask each one who holds the certificate, who renews it and what happens to your passes if you leave. The best wallet pass platforms guide has a checklist.

Troubleshooting checklist

If a pass will not add or stops updating, check in this order:

1. Is the certificate within its validity period?
2. Do passTypeIdentifier and teamIdentifier in pass.json match the certificate exactly?
3. Does every file in the zip appear in manifest.json, with the correct hash?
4. Is the WWDR intermediate current?
5. For updates: is the web service HTTPS, and does it return 304 or a freshly signed pass as expected?
6. Does the file open cleanly in the pkpass validator?

Common questions

Can I use one certificate for several Pass Type IDs? No. Each certificate belongs to one Pass Type ID.

Does renewing change my customers' passes? No. The new certificate signs future passes and updates under the same identifier.

Do I need a Mac? No. A CSR can be generated with OpenSSL, though Keychain Access is the path Apple documents most.