Tutorials

Share iOS Certificates Across a Team: .p12 Distribution

Last updated 2026-10-23

To share iOS certificates across a team, the safest setup is one distribution certificate for the whole team, created by the Account Holder or an Admin. Protect the exported .p12 with a strong password, send the file and the password to the people and build machines that need them through two separate channels, and a month before expiry follow a checklist to create a new certificate, regenerate the provisioning profiles and replace the files on every machine.

This tutorial turns roles, distribution, per-machine setup, renewal and rotation, and offboarding into checklists you can follow, with an asset register template at the end. Apple’s rules are as of October 2026.

If you don’t have certificates and provisioning profiles yet, create them first with Get an iOS certificate, p12 and provisioning profile on Windows. For how certificates, profiles and bundle IDs relate, see Bundle ID, App ID, Team ID, certificates and provisioning profiles.

Apple’s certificates overview makes two points.

Distribution certificates belong to the team. Each team can have only one of each distribution certificate type (Developer ID aside), and only the Account Holder or an Admin can create them.
Development certificates belong to individuals. In the developer account, each development certificate name ends with the computer name, for example Gita Kumar (Work Mac), so you can tell whose computer it’s for.

So there should be one distribution certificate, requested by one person, exported as a .p12 and handed to the colleagues and build machines that need to build packages. When everyone clicks the plus button on their own, this usually happens.

The portal won’t let anyone create another one, or someone revokes the one a colleague is using to make room. Every profile based on it becomes invalid immediately, and every Ad Hoc build your colleagues have stops opening.
The certificate selected in a profile doesn’t match the .p12 on your machine. The build reports that no matching certificate was found, and nobody can say which certificate belongs to whom.
Private keys end up on several people’s computers, and when someone leaves nobody knows which certificate to replace.

Development certificates can be one per person or shared. The next section covers the trade-off.

Who on the team can create and manage certificates?

Members of an organization account are managed in Users and Access in App Store Connect. The table below is taken from Apple’s role descriptions and lists only the rows related to certificates and profiles.

Action	Account Holder	Admin	App Manager	Developer
Create and revoke development certificates	Yes	Yes	With certificate access	With certificate access
Create and revoke distribution certificates	Yes	Yes	With certificate access	No
Create development profiles	Yes	Yes	With certificate access	Only through Xcode automatic signing
Create and delete distribution profiles	Yes	Yes	With certificate access	No
Download profiles	Yes	Yes	With certificate access	With certificate access
Register device UDIDs	Yes	Yes	With certificate access	Only through Xcode automatic signing
Generate App Store Connect API keys	Yes	Yes	No	No

“Certificate access” means access to Certificates, Identifiers & Profiles, which you grant to individual members in Users and Access in App Store Connect. Apple’s revoking privileges reference also says that every member can revoke their own development certificate, that the Account Holder and Admins can revoke other members’ development and distribution certificates, and that Admins can’t revoke the Account Holder’s own development certificate.

Split the work along these lines.

Certificate owner. One Admin creates the distribution certificate, generates and updates all profiles, registers devices and maintains the asset register described below. Name a backup owner so someone can step in when the owner is on leave.
Developers. The Developer role is enough. Grant certificate access to those who need to download profiles themselves.
Individual accounts. There’s only the account holder, so you do everything yourself.

One development certificate per person, or one shared

Approach	Good for	Benefits	Costs
One development certificate per person	Teams with more turnover, members with certificate access	When someone leaves, revoke only their certificate without affecting anyone else. The portal shows who signed a build	The Development profile must include everyone’s certificate, so you regenerate and redistribute it each time someone joins
One shared development certificate	Small teams of three to five, members with only the Developer role	Only one .p12 to maintain, and profiles don’t change with team changes	When anyone leaves, the certificate has to be replaced on everyone’s machine at once

A Development profile can include several development certificates, so one file serves everyone. The one-certificate-per-person approach doesn’t need a profile per person.

Which channels are safe for distributing a .p12?

A .p12 contains the private key, and anyone with the .p12 and its password can sign in your team’s name. Follow these rules.

Use a strong export password

When you export the .p12, set a long random password, not 123456 or your company name. Let a password manager generate it, or generate a 32-character random string with OpenSSL.

1$openssl = "C:\Program Files\Git\mingw64\bin\openssl.exe"
2& $openssl rand -base64 24

GitLab masked variables require values of at least 8 characters, so a password that’s too short can’t be masked in CI. That’s one more reason to use a long one.

Send the file and the password separately

Keep the .p12 in a team vault or an encrypted shared drive, and give the password through a different channel, such as a shared password manager item, in person or by phone.
Don’t put the .p12 and its password in the same email or chat message. Chat history and email sync to many devices and are hard to delete completely.
Don’t share the .p12 through a public file-sharing link.

Store it in a password manager or team vault

Password managers such as 1Password and Bitwarden support shared team vaults with file attachments. Create a vault that only the certificate owner and the people who build packages can access, with one item per certificate.

Item field	What to put there
Attachment	distribution.p12 (and the private key ios.key used to create it, if needed)
Password	The .p12 export password
Notes	Certificate type, Team ID, expiry date, serial number, creator, creation date
Related items	The profiles that use this certificate and the matching secret names in CI

Provisioning profiles contain no private key. You can keep them next to the certificate or commit them to the repository, as described in Build iOS apps with Jenkins and GitLab CI.

Keep it out of Git

The keychain folder in the project contains the .p12 and password.properties, so always add it to .gitignore. These lines keep the certificate folder, private keys and password files out of the repository.

1# Certificate folder, contains private keys and passwords
2keychain/
3
4# Signing files anywhere else
5*.p12
6*.p8
7*.key
8password.properties

*.p8 files are the private keys of App Store Connect API keys and APNs keys, and they don’t belong in the repository either. If one was already committed, adding it to .gitignore doesn’t remove it from history. Treat that certificate as leaked and replace it with the rotation steps below.

Use secrets in CI

On build machines, keep certificates in the CI system’s secret store, write them to a certificate folder at build time, point the CODE_SIGN_KEYCHAIN build setting at it, and delete it after the build. Restrict the distribution certificate secrets to protected branches and tags, so pipelines on ordinary branches can’t get the private key.

For GitHub Actions, see Build an iOS app and .ipa with GitHub Actions on a self-hosted Linux runner. For storing the API key used to upload, see upload .ipa files with an App Store Connect API key.

Where does the certificate go on each development machine?

When you build with KXBuild on Windows or Linux, put the .p12, the .mobileprovision files and the password file password.properties in the keychain certificate folder, following the rules in Certificates and signing. The certificate folder can live in two places, and certificates from both are used together.

Location	Scope	What to put there
`<project folder>/keychain/`	This project only	Profiles used only by this project
`KXBUILD_HOME/keychain/`	Shared by all projects. By default `%USERPROFILE%\kxbuild\keychain\` on Windows and `~/kxbuild/keychain/` on WSL, Linux and macOS	Development and distribution certificates shared by the team

Put the team’s shared .p12 files in KXBUILD_HOME/keychain/. You set it up once per machine, every project can use it, and a forgotten .gitignore entry can’t leak the private key into a repository.

1keychain\
2├─ development.p12
3├─ distribution.p12
4├─ MyApp_Dev.mobileprovision
5├─ MyApp_AppStore.mobileprovision
6└─ password.properties

password.properties has one line per certificate in the form filename=password. The file name must match the .p12 exactly and the password has no quotes.

1development.p12=password-copied-from-the-vault
2distribution.p12=password-copied-from-the-vault

If you edit password.properties in Windows Notepad, save it as UTF-8 and make sure there are no trailing spaces. If you build in WSL, the certificate folder is ~/kxbuild/keychain/ inside WSL. See Certificates and signing for copying files from Windows.

Once the files are in place, every build signs automatically according to the project’s signing settings. The certificate type comes from CODE_SIGN_IDENTITY, the team from DEVELOPMENT_TEAM, and with automatic signing the profile is matched by bundle ID and team. See Certificates and signing for the selection rules. Connect a phone, build and install once to confirm everything is in the right place.

1kxbuild build .\MyApp.xcodeproj --install

Share the same certificates with Mac teammates

The same .p12 works for Mac teammates and for teammates on Windows and Linux. You don’t need a separate certificate per operating system.

Mac teammates double-click the .p12 to import it into Keychain Access, and Xcode can sign with it. If they use KXBuild on macOS, they can also use the certificate from the system keychain. If the import says the password is wrong, macOS most likely doesn’t recognize the default encryption format of OpenSSL 3. Export it again with -legacy as shown in the make-p12 section.
Windows and Linux teammates put the same .p12 in the keychain certificate folder and write password.properties.
The project’s signing settings are shared, so don’t change them separately. DEVELOPMENT_TEAM, the signing style and CODE_SIGN_IDENTITY are committed in project.pbxproj. When a Mac teammate changes signing settings, they should tell the team.

For other conventions in a shared repository, such as a complete .gitignore and marking schemes as Shared, see Open and build an Xcode project on Windows alongside Mac teammates.

How do you rotate and renew before expiry?

You need a new certificate when the current one is expiring, when the private key may have leaked, or when someone holding the private key leaves. The process is the same in all three cases. Only the urgency differs.

How early to prepare

Expiry dates for certificates and profiles are on the Certificates and Profiles pages in the developer account. You can also check local files with OpenSSL. The commands are in the section on checking expiry dates in What happens when an iOS certificate expires or is revoked.
Put every certificate and profile expiry date in a team calendar, with a reminder to the certificate owner one month ahead.
Schedule the renewal between releases, away from times when a build is in review or TestFlight or Ad Hoc testing is under way.

Before you start, read What happens when an iOS certificate expires or is revoked to understand the impact of each. In short, while your membership is active, an expired or revoked distribution certificate doesn’t affect apps already on the App Store. Revoking it does invalidate every profile that includes it immediately, and Ad Hoc and development builds stop opening.

Renewal checklist

Step	Who	What	Done when
1. Create the certificate	Certificate owner	Generate a CSR (you can reuse the existing private key), create a new certificate of the same type on the Certificates page, build a new .p12 and set a new strong password	The vault has a new item with the expiry date in the notes
2. Regenerate profiles	Certificate owner	On the Profiles page, edit each profile that used the old certificate, select the new certificate, save and download. Cover the main app and each extension, and Development, Ad Hoc and App Store Connect profiles	Every profile in the register has an updated date
3. Distribute the new .p12	Certificate owner	Put the new .p12 and profiles in the vault, send the password separately, and announce a replacement deadline	Every holder confirms receipt
4. Replace on each machine	Every holder	Delete the old .p12 and profiles from the `keychain` folder, add the new files and update password.properties	Only new files remain in the folder
5. Replace in CI	CI owner	Update the three secrets for the .p12, password and profile	The pipeline picks up the new certificate
6. Verify builds	Every holder and CI	A development build installs and opens on a phone. A Release build with a higher build number uploads to App Store Connect	Every row in the register is checked off
7. Handle the old certificate	Certificate owner	If it’s expiring normally, let it expire. If it leaked or someone left, revoke it right after step 6 passes everywhere	Only the new certificate remains in the portal

The CSR and .p12 commands for step 1 are in the renewal section. For step 6 you can use these two commands.

1kxbuild build .\MyApp.xcodeproj --install
2kxbuild build .\MyApp.xcodeproj -c Release --export app-store

If the portal won’t let you create another distribution certificate of the same type while the old one is valid, you have to revoke the old one first. In that case move step 7 to the front, pick a window with no release, tell testers in advance that Ad Hoc builds will stop working for a while, and do steps 1 to 6 in one go.

Always delete the old files in step 4. With old and new copies in the same folder, the wrong one gets picked easily and the errors are harder to track down. See 16 common iOS code signing and .ipa install errors for the related errors and fixes.

What do you do on the day someone leaves?

On the person’s last day, the Account Holder or an Admin works through these steps in order.

Remove the team member. In Users and Access > People in App Store Connect, open the person, click Remove at the bottom left and confirm. Apple’s Add and edit users help page says this needs the Account Holder or Admin role and that it can take up to 10 minutes for cached access to be fully removed. Developer members of organization accounts are managed here as well. See Apple’s Delete team members.
Revoke their development certificate. On the Certificates page, find their development certificate by name and computer name and revoke it. Profiles that include it become invalid, so regenerate the shared Development profile on the Profiles page without their certificate and distribute it to everyone else.
Rotate any distribution certificate they had. If they had the .p12 and password of a distribution certificate, treat it as leaked. Replace it with the renewal checklist above and revoke the old one once verification passes. If the team shares one development certificate, replace that too.
Revoke API keys. In Users and Access > Integrations > App Store Connect API in App Store Connect, revoke the individual keys they created and any team keys whose .p8 they downloaded, then generate new team keys and update CI.

Apple’s App Store Connect API help page says revoked keys can’t be restored and that lost or leaked keys should be revoked immediately. If they also had access to the APNs .p8 key used for push, replace it on the Keys page of the developer account. See p8 or p12 for push notifications.
Change vault and CI access. Remove them from the team vault, the CI system and build machine accounts, and change any shared passwords they knew.
Collect devices. When their test devices are returned, disable UDIDs that are no longer used in the developer account.
Update the register. Reassign every row under their name to a new holder, or mark it as revoked.

Apple’s help pages don’t say what happens to the certificates a member created after they’re removed. Don’t count on removing the member to invalidate their certificates. Do steps 2 to 4 by hand.

Asset register template

Record every signing asset of the team in one table, kept in the team vault or in a document only the certificate owner can edit. Update it every time you create, distribute, rotate or revoke something, and work through it row by row during offboarding and renewal.

Asset	Type	Expires	Created by	Stored in	Holders and machines	Related profiles	Last rotated
distribution.p12	Apple Distribution certificate	2027-03-01	Alex (Admin)	Vault “iOS signing”, item 1	Alex’s Windows laptop, Sam’s MacBook, CI secret `IOS_P12_BASE64`	MyApp_AppStore, MyApp_AdHoc	2026-03-01
development.p12	Apple Development certificate (shared)	2027-02-10	Alex	Vault item 2	Development machines of Alex, Sam and Jordan	MyApp_Dev	2026-02-10
MyApp_AppStore.mobileprovision	App Store Connect profile	2027-03-01	Alex	Vault item 1, repository `signing/`	Same as distribution.p12	—	2026-03-01
AuthKey_ABC123.p8	App Store Connect API team key (App Manager)	—	Alex	Vault item 3	CI secret	—	2026-06-15
AuthKey_XYZ789.p8	APNs key	Doesn’t expire, can be revoked	Alex	Vault item 4	Push server	—	2026-01-20

The names and dates are examples. Replace them with your team’s details. The “Holders and machines” column matters most when you share iOS certificates, because when someone leaves or a key leaks, it tells you where files need replacing.

FAQ

Does everyone on the team need their own iOS distribution certificate?

No. Apple states that distribution certificates belong to the team and that each team can have only one of each type. The Account Holder or an Admin creates it, exports a .p12 and gives it to the colleagues and build machines that need to build packages.

Can the Developer role create certificates and profiles?

With certificate access granted, a Developer can create and revoke their own development certificate and download profiles, but can’t create distribution certificates or distribution profiles. Those are done by the Account Holder, an Admin, or an App Manager with certificate access.

Put the .p12 in a shared team vault in a password manager or on an encrypted shared drive, and give the password through a different channel. Don’t put both in the same email or chat message, and don’t commit them to a Git repository.

Do I need a new iOS certificate after a colleague leaves?

Replace every certificate whose .p12 and password they had, and revoke the API keys they had access to. Remove them in App Store Connect first, then create new certificates and profiles with the renewal checklist, and revoke the old certificates once every machine and CI passes verification.

Does a new certificate affect apps already on the App Store?

No. Apple states that as long as your Apple Developer Program membership is active, an expired or revoked distribution certificate doesn’t affect apps already on the App Store. Builds signed with the old certificate that haven’t been submitted yet may be marked invalid, so build and upload them again with the new certificate.