What is certificate, provisioning profile, and Bundle-identifier.

Apple’s security scheme for deploying applications to iOS devices is notoriously difficult and has created many headaches for developers through inscrutable error messages when deploying from Xcode.

However, Apple’s scheme is very flexible and currently allows for a number of different scenarios:

• – APP’s deployed from the App Store are trusted because they are cryptographically signed by Apple
• – Enterprise organizations can deploy applications to their employees without publishing to the app store (so called “Line of Business apps” that have no business being published to the general public)
• – APP developers can deploy development binaries to (up to 100 of) their own devices for testing
• – APP developers can run a beta program by directly deploying correctly-signed apps to customers

Here are some definitions for the components in Apple’s scheme:

Identifiers – Also referred to as “Application Identifiers” or “Bundle Identifiers”. They uniquely identify your application, and typically have a reverse domain name such as com.company.product

Certificates – This is a cryptographic certificate granted to you by Apple. It works just like SSL where you get a certificate signed by an authority. Apple signs the private key that you use to sign different pieces of your application. Different certificates create different types of trust. Some allow you to sign and submit your application for the App Store, while others allow your application’s web server to send push notifications to users via APNS. In the latter case, for instance, Apple uses this certificate to trust the web server sending the push notification. Otherwise, it would be easy for an attacker to spoof a valid push notification and spam users. The most common certificate you would create signs the key you use to deploy your application to a device or submit it to the App Store.

When you create a certificate through Apple’s developer portal, you have to create your key pair and send a “Certificate Signing Request,” which at first is likely pretty confusing to developers just trying to see their application run on a device.

If you visit the developer portal(https://developer.apple.com/), you’ll find you can create certificates for Development or Distribution. These certificates are rooted to different authorities, so that the two worlds are never confused (though all iOS devices trust both in a seemingly equal fashion).

Provisioning Profiles  – Probably the most confusing component in the system, a provisioning profile indicates the devices for which an application is correctly signed. If you visit the developer portal, you’ll notice you can create two types (again called Development and Distribution). Provisioning profiles say “applications with this Identifier signed with this Certificate’s private key are okay to run on these devices.” Now that you know a provisioning profile is tied to a certificate, you can see why you have to decide whether to create a Development or Distribution profile. Development profiles are limited to 100 devices. Distribution profiles can either be Ad-Hoc or App Store distribution profiles. I am not sure whether Ad Hoc profiles have device limits.

You might ask, then, why not always use a Distribution profile? It can deploy to an unlimited number of devices, and is still attached to a certificate owned by the developer. Another piece of Apple’s security puzzle are Entitlements. In an iOS application’s bundle, you’ll find Entitlements.plist, which is a list of capabilities that an application wants. When signing your application using a certificate intended for distribution, Xcode (really the signing utility) will not allow an entitlement with get-task-allow set to YES. This is because get-task-allow is what allows a debugger to connect to a process, and Apple doesn’t want that happening on apps meant for distribution.

Credit: Apple Developer Programme