Apple Certificate — What It Is, Types and How It Works

What is an Apple Certificate

Apple Certificate is a cryptographic certificate in X.509 format issued by the Apple Certificate Authority. It confirms that its holder is a registered member of the Apple Developer Program and has the right to sign applications for the Apple ecosystem. The certificate consists of a public key, owner metadata, and a digital signature from the Apple CA — anyone can verify the authenticity of the certificate using the Apple root certificate built into the operating system.

Apple’s PKI architecture includes three levels: the Apple Root CA, the intermediate certificate (Apple Worldwide Developer Relations CA), and the developer certificate. Apple Worldwide Developer Relations CA signs all developer certificates — if this intermediate certificate is missing from the trust chain, the code signature is considered invalid. Apple root certificates are updated automatically through the Apple Trust Store mechanism built into iOS and macOS.

Each certificate has a validity period — from one to three years, depending on the type. Apple Developer Program automatically notifies the developer 30 days before certificate expiration via email and push notifications. After expiration, the old certificate cannot be used to sign new builds — a new one must be issued; however, applications signed with the expired certificate continue to work on users’ devices.

Apple Trust Chain

The trust chain ensures that the developer certificate was actually issued by Apple. iOS verifies: the Apple Root CA certificate (built into the firmware), the intermediate Apple Worldwide Developer Relations CA certificate, and the developer certificate. If any element of the chain is missing or invalid, iOS blocks the app launch with a code signing error. macOS provides the security utility to check the trust chain of any certificate in the keychain.

How Apple Certificates Work

The code signing process using an Apple Certificate is based on asymmetric cryptography. The private key is stored on the developer’s computer in Keychain, while the public key is included in the certificate and sent to the Apple Developer Portal. When Xcode signs an application, it creates a digest (hash) of the binary file and encrypts it with the private key — this is the digital signature. The device decrypts the signature using the public key from the certificate and compares it with the computed hash.

Apple uses the ECDSA (Elliptic Curve Digital Signature Algorithm) with the P-256 curve for all certificates issued after 2021. Previously, RSA-2048 was used. The transition to ECDSA increased signature verification speed on devices and reduced signature size — this is especially important for mobile applications, as signature verification is performed on every launch. According to Apple Security Engineering (2025), ECDSA P-256 provides an equivalent security level to RSA-2048 with significantly lower computational costs.

For CI/CD processes, the certificate along with the private key must be exported to PKCS12 (.p12) and stored in a secure vault. GitHub Actions, Bitrise, Jenkins, and other CI systems support importing certificates via environment variables or secrets. After import on the CI agent, the certificate is temporarily added to the keychain, used for signing, and then removed. Fastlane Match automates this process by synchronizing certificates between developers through an encrypted git repository.

Difference Between Development and Distribution Certificates

Development certificate allows signing applications to run on the developer’s physical devices. A free Apple ID account is sufficient to obtain it — Xcode can generate a Development certificate automatically. Distribution certificate is issued only for paid Apple Developer Program accounts ($99/year) and is required to submit an app to the App Store, for Ad Hoc distribution, or Enterprise distribution. One account can have multiple Distribution certificates — for example, separate ones for each application or for different teams.

Types of Apple Certificates

The Apple Developer Portal provides several types of certificates, each designed for a specific purpose. iOS App Development — basic certificate for signing applications during development. Apple Distribution — main certificate for publishing in the App Store. Mac Development and Mac Distribution — counterparts for macOS applications. Each certificate type requires a separate request (CSR) in the Apple Developer Portal.

A separate category consists of certificates for push notifications. Apple Push Notification service (APNs) requires either a separate SSL certificate or the use of authentication tokens (APNs Auth Key). APNs SSL certificates are issued separately for Development (Sandbox) and Production environments and are tied to a specific App ID. APNs Auth Key is a more modern approach: one key (.p8) serves all applications in the account, simplifying management.

Creating and Managing Certificates

Creating an Apple Certificate begins with generating a Certificate Signing Request (CSR) through Keychain Access on macOS. Keychain Access creates a key pair: the private key remains in the keychain, while the CSR is sent to the Apple Developer Portal. After identity verification, Apple signs the CSR and issues a ready certificate (.cer), which needs to be downloaded and installed by double-clicking.

For managing multiple projects and teams, Apple provides the ability to create certificates for different Team IDs. One developer can be a member of multiple teams (through Apple Developer Program — App Store Connect), and separate certificates are issued for each team. Xcode automatically switches certificates based on the selected team in the Signing & Capabilities settings.

Revocation of a certificate is a critical operation: all applications signed with this certificate stop installing on new devices (already installed ones continue to work). Apple Developer Portal allows revoking any certificate in the Certificates section. Reasons for revocation: private key compromise, developer leaving the team, violation of Apple Developer Program terms. After revocation, a new certificate must be issued and all active builds must be re-signed.

Keychain and Certificate Export

Keychain is the macOS system storage for certificates, private keys, and passwords. All Apple certificates and corresponding private keys are stored in the user’s login keychain (login.keychain). Xcode accesses Keychain when signing code, automatically selecting the appropriate certificate based on the build type. For diagnosing signing issues, the built-in Keychain Access utility (/Applications/Utilities) is useful.

Exporting a certificate for CI/CD is done through Keychain Access: select the certificate and the corresponding private key (they should be expanded in one row), right-click and choose Export. The format is PKCS12 (.p12). During export, Keychain will ask for a password to protect the file — this password will be required when importing on the CI server. Without the private key, the exported certificate is useless for signing — it can only be used to verify already signed code.

Importing a Certificate in CI/CD

Example command for importing a certificate into the CI agent’s keychain using the security utility:

# Creating a temporary keychain
security create-keychain -p "temp" build.keychain
security default-keychain -s build.keychain
security unlock-keychain -p "temp" build.keychain

# Importing a certificate from .p12
security import certificate.p12 -k build.keychain \
  -P "${P12_PASSWORD}" -T /usr/bin/codesign

# Configuring signing policy
security set-key-partition-list -S apple: -s \
  -k "temp" build.keychain

Security create-keychain creates a temporary keychain isolated from the user’s. This is important for CI to avoid polluting the agent’s system keychain. The -T /usr/bin/codesign flag allows the codesign utility to access keys without a password prompt — otherwise, automatic signing in the pipeline would be interrupted by a dialog. The set-key-partition-list command is necessary for compatibility with macOS code signing requirements in automated mode.

Certificate Issues and Solutions

The most common error is “No signing certificate found” when building in Xcode. It occurs when Keychain lacks a certificate with a private key matching the selected build type. Solution: check Keychain Access for the certificate, download it from the Apple Developer Portal and install it. If the private key is lost (old computer, system reinstall), the old certificate must be revoked and a new one issued.

The “Valid signing certificate not found” error in CI/CD occurs if the agent does not have Apple’s intermediate certificates installed (Apple Worldwide Developer Relations CA). Apple includes intermediate certificates in the chain when downloading the developer certificate, but they may be missing when manually exporting .p12. Solution — download the intermediate certificates from the Apple Certificate Authority website and install them into the CI agent’s keychain.

An expired certificate issue manifests as the error “This certificate has an invalid issuer” when signing. The Apple Developer Portal shows the status of each certificate and its expiration date. If an application is already published in the App Store with an expired certificate, it continues to work — the App Store uses Apple’s own certificate for distribution. However, uploading a new build requires a valid Distribution certificate. Fastlane includes the cert command for automatically creating and renewing certificates.