For internal enterprise app distribution, this guide walks through the full process of applying for an iOS enterprise developer account, generating an In-House certificate, configuring a Provisioning Profile, and installing an IPA. It addresses three common pain points: unreliable shared certificates, opaque workflows, and error-prone configuration. Keywords: iOS enterprise signing, In-House certificate, Provisioning Profile.
The technical specification snapshot
| Parameter | Details |
|---|---|
| Target platform | iOS |
| Account type | Apple Developer Enterprise Program |
| Distribution method | In-House internal distribution |
| Key prerequisite | A registered company entity, typically with complete organizational credentials |
| Core identifier | D-U-N-S Number |
| Core artifacts | CSR, CER, P12, Provisioning Profile, IPA |
| Related agreement | Apple Developer Program License Agreement |
| Tools mentioned | Apple Developer, yunedit |
| Star count | Not provided in the source |
| Core dependencies | Apple Developer portal, certificate tools, enterprise bundle ID configuration |
The enterprise developer account is only for internal app distribution
An iOS enterprise developer account is not a shortcut to avoid App Store review. It is specifically intended for proprietary apps used within an organization. If your app targets public users, requires internet-facing distribution, or will be published on the App Store, you should use a standard company developer account instead of an enterprise account.
Using someone else’s shared enterprise certificate may let you produce a build in the short term, but it carries extreme risk. Once Apple determines that a certificate is being misused, the most immediate result is certificate revocation. Installed apps will then fail to launch. The only stable approach is straightforward: your company applies for its own account, issues its own certificates, and maintains its own profiles.
Shared certificates are not recommended for good reason
Shared certificate -> Reused by multiple teams -> Uncontrolled distribution behavior -> Apple risk controls are triggered -> Certificate becomes invalid -> App can no longer openThis chain shows that the root cause of certificate risk is not a technical signing failure. It is a loss of account compliance control.
You should prepare company information before applying
The source material notes that applying for an enterprise account has a threshold. In practice, Apple reviews the legitimacy of the organization, the identity of the contact person, and the explanation of the internal-use scenario. Before you apply, align the company name, address, phone number, and legal representative information so they match your public business records.
The first critical prerequisite is the D-U-N-S Number. You can think of it as your company’s unique identifier in the global business identity system. Apple uses this identifier during organization verification.
The D-U-N-S Number application entry point is here
https://www.dnbportal.cn/duns/applyThis portal is used to apply for a company D-U-N-S Number, which is an important prerequisite for Apple’s enterprise account review.
The Apple enterprise account application entry appears only after scenario selection
The Apple enterprise account application page does not immediately present a form. After opening the official page, you must first choose the intended app usage. In most cases, the system displays the application button only after you select “Proprietary apps used internally within my organization.”
The official entry point is:
https://developer.apple.com/cn/programs/enterprise/At its core, this step explicitly declares the distribution boundary to Apple: the app is for internal organizational use only, not for the public market.
AI Visual Insight: This screenshot shows the trigger condition for the application entry on the Apple Developer Enterprise Program page. The key detail is that you must first select the scenario for proprietary apps used only within your organization before the formal application button appears at the bottom of the page. This shows that Apple uses the interface flow to filter distribution intent before opening the enterprise enrollment process.
The certificate generation process moves from CSR to CER to P12
Enterprise certificate generation consists of three steps: create a CSR, issue a CER in the Apple Developer portal, and export the CER as a P12. Many teams get stuck on the second and third steps because they do not clearly distinguish between a certificate request file and a private-key-backed signing file.
The first step is creating a CSR certificate signing request
A CSR is the request file you submit to Apple when applying for a signing certificate. It contains the public key and subject information. The source article uses yunedit to create the CSR, which is a tool-based approach suitable for teams not using macOS Keychain.
# Example: a typical process for creating a CSR with OpenSSL
openssl genrsa -out enterprise.key 2048 # Generate a private key
openssl req -new -key enterprise.key -out enterprise.csr # Generate a CSR request file from the private keyThese commands generate the private key and CSR required as standard input for Apple to issue the enterprise certificate.
The second step is selecting an In-House certificate in the developer portal
After signing in to Apple Developer, open the Certificates menu and create a certificate. You must choose the In-House type here, because it is intended for enterprise internal signing rather than App Store or Ad Hoc distribution.
AI Visual Insight: This image shows the certificate management area in the Apple Developer portal, where you create an enterprise certificate from the Certificates menu. Technically, this step determines the certificate usage category. If you select the wrong certificate type, the resulting Profile and installation distribution workflow will not match.
After you upload the CSR, Apple returns a .cer file. This file is the issued certificate, but it cannot yet be used directly in most automated packaging workflows.
The third step is converting the CER into a P12 file for signing
A P12 file is essentially a packaged format that contains both the certificate and the private key. CI systems, cloud build platforms, and cross-machine signing workflows commonly use it. The source article still uses yunedit to export the P12 and requires a password with at least six characters.
AI Visual Insight: This screenshot shows the interface for packaging an issued CER certificate into a P12 file. The key technical point is that after uploading the CER, you combine it with the original private key to export a password-protected P12. This step determines whether the certificate can be correctly loaded in automated builds, remote signing, or multi-environment deployment.
# Example: export the certificate and private key as a P12 with OpenSSL
openssl pkcs12 -export \
-out enterprise.p12 \
-inkey enterprise.key \
-in enterprise.cer # Package the certificate and private key into a P12 fileThis command combines the CER and private key into a P12 for subsequent IPA signing.
The Provisioning Profile must be bound precisely to the App ID and certificate
Even with a P12, you still cannot publish directly. You also need to create a Provisioning Profile. The core purpose of the Profile is to bind the App ID, certificate type, and distribution permissions together into an installable signing authorization.
It is best to split the process into two steps: create the App ID first, then create the In-House Profile. The App ID usually follows reverse-domain notation, such as com.company.app, and it must exactly match the Bundle Identifier configured in your project.
The minimum logic chain for creating a Profile is simple
App ID (bundle ID) -> In-House Profile -> Bind the correct certificate -> Export the provisioning file -> Use it for IPA signingThis chain makes it clear that a Profile is not a standalone file. It is the binding layer in the signing system.
If multiple certificates exist in the account, verify carefully during Profile creation whether the certificate has expired and whether it is the currently active version for the target app. An incorrect binding can cause installation failures, signing validation errors, or interrupted app updates.
After IPA packaging, you can move into internal installation and distribution
Once the P12 and Profile are ready, you can generate an IPA in Xcode, uni-app, or any other packaging system. The source article describes a workflow in which the IPA is uploaded to an installation testing module, and the platform automatically generates a QR code and download page link for easy installation by scanning.
{
"bundleId": "com.company.internalapp",
"certificate": "enterprise.p12",
"profile": "InHouse.mobileprovision",
"output": "internal-app.ipa"
}This configuration illustrates the four key inputs for enterprise signing and packaging: the bundle ID, the P12, the Profile, and the output IPA.
You should proactively avoid three key implementation risks
First, an enterprise account must not be used for large-scale public distribution, or you will face significant compliance risk. Second, certificates and Profiles must be managed as pairs to avoid version confusion caused by multiple maintainers. Third, certificate passwords, private keys, and provisioning files should live in a controlled access system and should never be shared in plain form through instant messaging tools.
A minimum governance strategy is strongly recommended
Standardize company entity information
Standardize Bundle ID naming conventions
Standardize certificate ownership and rotation procedures
Standardize the archive directory for Profile versionsThis minimum governance model can significantly reduce the probability of certificate revocation, incorrect signing, and delivery interruptions.
FAQ
1. What is the difference between an iOS enterprise developer account and a standard company developer account?
An enterprise developer account is used for In-House distribution of apps within an organization. A standard company developer account is mainly used for App Store publishing, TestFlight, or normal commercial release workflows. The compliance boundaries are completely different and should never be mixed.
2. Why is it not recommended to buy or borrow someone else’s enterprise certificate?
Because the actual user and distribution behavior of a shared certificate are uncontrollable, this setup can easily trigger Apple’s risk controls. Once the certificate is revoked, every app installed with that certificate may stop launching. The business risk is far greater than the short-term convenience.
3. Are both the P12 and the Provisioning Profile required?
Yes. The P12 provides the signing certificate and private key, while the Profile binds the App ID, certificate type, and distribution permissions. Without either one, the IPA cannot be signed correctly or installed normally.
[AI Readability Summary]
This article systematically reconstructs the iOS enterprise developer account application workflow. It covers the D-U-N-S Number, the Apple Developer Enterprise Program, In-House certificates, Provisioning Profiles, and IPA installation and distribution, with a focus on applicable scenarios, common risks, and the fundamentals of enterprise signing.