we have a little Problem here and I hope you guys can help me out!
Situation:
We are enrolled in Apples Developer Program (for distributing Apps in the App Store). Since last week we're also enrolled in the Enterprise Program (for in-house App distribution).
Problem:
We proceeded with the development and building of the Apps. But we didn't knew that we have to use two different developer certificates for the different Programs. We have now 2 certificates with the same name and XCode is producing an error message each time we want to build the app saying "the certificate cannot be assigned exactly".
Question:
How do we change the name of one of the developer certificates?
Many thanks for your help in advance!!!
You already have default login keychain So you can add one certificate in login keychain. And then create new saperate keychain with different name and add your second certificate to that keychain. Now in your Xcode target setting find keychain certificate path to be used for target and choose appropriate keychain path.
e.g. For one certificate path ........./login/.....
For another certificate change path to ......../mynewkeychain/......
I feel your pain, as I have been in the same situation before. You can't easily change the certificates' names. Apple usually does not allow that. Dhawal's answer is correct, in that you will have to put your certificates into different keychains.
If you want to script your build process, you have to unlock and lock the appropriate keychains security unlock-keychain before you call xcodebuild. So that only the one certificate you want to sign with is accessible.
There are two very good projects that make managing the keychains and building a lot easier:
Openbakery's Gradle Xcode Plugin
rayh's xcoder for use with rake
Related
Xcode as of 6.3 is no longer allowing me to automatically perform device provisioning for a client. Has anyone else experienced this issue? I found no results when searching for this on Google...
This client has their own bundle ID and it's possible they also have their own provisioning profile for this device. So maybe Apple is matching up the bundle ID irrespective of the developer account being used for provisioning.
I was able to address the issue by modifying the app's bundle ID and manually going through the provisioning process, but I'm guessing this issue is extremely rare, so I'm not sure if this post will be of use to anyone.
When I am create new certificate from my Xcode 9.2 the error was appear
"You already have a current iOS Distribution certificate or a pending certificate request".
Just 2 step for fix this error.
Remove old certificate from developer.apple.com
Create new certificate from Xcode or developer.apple.com
My problem has been solved (I am using Xcode 9.2).
I just found that if I remove my account from Xcode, and then sign in again, it solved the issue. I did revoke my existing certificates and request new ones though as part of that process. I didn't import an existing profile.
My team has maxed out on release certificates, because apparently there is a quota.
We had to delete one of the existing release certificates.
This issue is actually more common than you think.
Some Solutions:
I usually find that opening Xcode's settings and signing out of my account and the signing in again resolves most of those issues.
You may have an older mac that already used up that one allotted development certificate. In that case you'll want to export the developer profile from that machine. If you no longer have access to that machine, it may be time to invalidate that certificate and simply request a new one.
Another option may be to double check your build settings in your project and ensure that it's looking for the right certificate. It's fairly common in my experience for these settings to make decisions on their own, and confirming that they're what you expect may help.
Background:
When dealing with provisioning, it's really easy to get caught up with the frustration of all of the steps you need to go through. The first thing to note is if the error you see is talking about a "Certificate" or a "Profile." In your case, it's a certificate. Good.
Certificates differ from provisioning profiles in a few ways. Certificates are usually only generated twice: once for development, and once for distribution. (Exceptions to this rule are if you decide to add support for some of the special features like push notification or for generating passbook passes on a server.)
The process for generating certificates is also a little more bureaucratic than profiles. You request a certificate from Apple's Member Center. You generate a provisioning profile.
The reason for the word request vs generate is because both Apple and your iOS team's admin need to approve certificate requests. This is because certificates identify you as part of your iOS developer team, and offer all the powers associated with that.
For the sake of completeness, I'll add that provisioning profiles are generated based on that certificate, and really only tell iOS what environment your app is meant to run in. (On any device via the store, specific devices, etc.)
Now, the important part for you is the request business. Most people don't pay much attention to this terminology, since indie developers and small teams (where the developers are admins) don't require developers to ask for permission.
Your error is talking about a previously generated certificate or request. You can only have one development certificate per developer. You either have one, or you've requested one and someone has to approve.
That's what's happening here.
This process is made simple with Xcode 8.3 and 9. Just delete one of your old certifcates in the "validate" interface and click the plus button to request new one, Xcode will request for you and add it in keychain. in my case, maximum number was reached, so I deleted one which was lost in a old Mac and created new one.
This error may also be occur if you reach your distribution certificate limit. After creating 3 iOS Distribution Certificates in an account, the following error message will be displayed when you try to create 4th one: "You already have a current Distribution certificate or a pending certificate request."
Open this link
https://developer.apple.com/account/resources/certificates/add
Press + icon in front of Certificate
Check Apple Distribution section if its show the red text as shown in image then you should revoke you existing certificates to generate new one because you have reached you limit.
Just 2 step for fix this error.
Remove old certificate from developer.apple.com
Create new certificate from Xcode or developer.apple.com
Delete old developer certificate from https://developer.apple.com/account/ios/certificate/ and try to create developer certificate from xcode
1) Remove old certificate from apple developer account.
2) Go to the 'Xcode' 3) Select 'Preferences' option and then Select the 'Account' Tab
3) Select apple id from left side and click on 'Manage Certificate'.
4) Click on '+' (add certificate) button.
5) Add 'Apple Distribution' Certificate.
Unfortunately, only a macbook restart resolved this for me.
Creating another Distribution certificate was not an option, because it had already reached the max. number of certificates.
I manually added an existing one (incl. its private key) to the Keychain …and still Xcode said "Not in Keychain". I then tried to trigger a refresh of the Xcode listing by removing & adding my developer account to Xcode, but that didn't work — neither did restarting Xcode.
So, when all else fails, you try to reboot your system.
When you have three active distribution certificates that were created on distinct machines, you'll see this issue. You can either ask for the private key of a previously made one or simply revoke any of them and make your own.
I need to create a distribution App Store build for a client who doesn't have Xcode. Is there a way to do this without the client needing to give me credentials to their Apple Developer account?
I do see other questions that are similar,but a bit different, as they want the client to be able to re-sign on their end. Also, the questions are all a year or more older, and I'm hoping that this likely common situation has a simpler solution.
If all you want to be able to do is resign the code with their signing certificate then you can use a tool called iResign. It would let you create a distribution build with one cert and then have it resigned with a different cert. it's perfect for working with clients or providers who don't want to share credentials.
You want to create a distribution build created with the client's credentials? Not possible unless the client gives you his credentials or sets you up with your own credentials as a member of his time.
Probably the cleanest way to do this is for the client to set you up as a team member on his team, issue you a certificate and a distribution provisioning profile, and then you build with that. I don't remember for sure if you have to be an admin to create a distribution build or not. I don't think so, but I'd have to check.
Check out Testflight. You just need the UDIDs of any devices that the client may test on. The app is then e-mailed out and the client can open and install.
Ok, I am completely pulling my hair out on this one.
Back in July I created a provisioning profile so I could test on my iPad.
Then at the end of August I tried submitting my first App to the iTunes Store. The process was a complete nightmare, and I struggled. A lot. In the end I found a tutorial with relatively recent information in it, and only by following it step by step could I actually get anywhere with this. Unfortunately the result of this was that I created a new provisioning profile.
Now when I try to test on my iPad I get the following error in Xcode:
Certificate identity 'iPhone Developer: MyName' appears more than once in the keychain. The codesign tool requires there only be one.
I check the keychain, and sure enough there are the two provisioning profiles for development, one from July and the one I used to submit to the iTunes Store in August.
Now what I want to do is get rid of the old one, and then connect my iPad up to the new one. I can get rid of the old one fine, but I cannot connect my iPad to the new one, it insists on using the old profile, even to the point of re-attaching it to the keychain after Ive deleted it.
Can anyone tell me:
How to connect my iPad to the new provisioning profile?
And while we are at it, can anyone shed any light on why this entire process is so convoluted and difficult? Considering that so much of Apples interface is so well designed and fluid, this process of registering certificates and applying them to different devices and Apps seems so backwards. I initially suspected this was just me, but googling for these error messages reveals that there are many who are struggling at various points along this process.
This has nothing to do with Xcode and everything to do with keychain.
Open keychain.
Find the signing certificates that are tied to your provisioning profiles.
Delete one. You probably want to keep the newer one, so look at the expiration dates and remove the one that expires first.
Restart Xcode
You may need to update your provisioning profile if it isn't tied to the new certificate, but it won't be as painful as creating a new certificate.
Here's a broad overview of how code signing in Xcode works. It a bit much but will explain what's wrong with your configuration, and how you can fix it.
There are three parts to the mechanism that ensures that you are who you say you are and that your app is allowed to run where it wants to.
You've got a pair of keys, one public and one private. Your public key matches your private key, which identifies you.
Your keys are used to generate certificates. Generally, you'll have one certificate for development and one for distribution,either on the App Store or via Ad Hoc distribution. These certificates permit you to provision your apps.
Each certificate is used to generate provisioning profiles. The profiles must be attached to either a development or a distribution certification. A distribution profile either works on the App Store, or it contains a list of device IDs which may run apps signed with that profile.
If your certificate is expired, the provisioning profiles that are created with it are going to be invalid. In this case, replace both the certificate and the profiles. Generate a certificate signing request (CSR) from Keychain Access and upload it to the developer portal.
If you have multiple certificates in your keychain, Xcode won't know which one to use. This may happen if you renew your certificate and don't remove the old one. (It may also happen if you exported your developer profile and then imported it later. Your old certificates will carry over.)
If your provisioning profile is expired or invalid, you can renew it in the developer portal without generating a new CSR. You can just attach it to an existing valid certificate.
Certificates can't be carried over from one machine to another without moving the original key pair that requested it. Exporting the certificate from Keychain will export the keys as well.
Delete the old one, and start build with new.
One more way you can try , set code signing identity with profile you want to run in both target as well as project build setting.
Hope it will help you.
Otherwise you have to delete old one.
There is a lot of information about iOS distribution. I think I understand the different distriubution models, but I am looking for best practice for distributing an app to a client.
I have a client who has an Enterprise developer account and uses AirWatch for MDM. Here is how I am going to recommend to them that we distribute the app to their organization since they have no one technical on staff that has any experience with Xcode or iOS development and they will not be given access to the source code:
Add me as a member of their developer account
I build the app using their certificate
I give them the .ipa and plist file to distribute either through MDM or website.
Is this the correct way to do this? What if I am going to sell this same app to three clients - would I do it a different way? Is there anything else that needs to be done to distribute through AirWatch?
Again, looking for best practice and how others are handling this situation. Please clarify if I have anything wrong.
UPDATE: Thank you all for the answers. From what I have learned how this is done depends directly on how the client wants to handle the situation. In the end the client added me as an admin on their account (we have worked together quite a bit). I was able to create the distribution profile, build, and deploy the app to them. Not all clients will do this for security reasons. In that case, they will need to provide you will a cert as stated below, or you will need to build the app on one of their machines as Buckeye said below...or go through Apple to distribute the app to them.
Feel free to correct any of this info if it is incorrect. I really think this is helpful information for a lot devs.
I am accepting Patrick's answer because it is the closest to what I actually did.
There are two ways you can do this, but for both you must be added as a member of your client's developer team. Once you have done this, you (or more likely your client) will choose weather to use their in-house certificate or your own distribution certificate that you will manage.
It can be done either way, it is only a matter of who will have authority in the future to submit apps with the same certificate under the same account. That authority resides in the possession of the associated key pair of the certificate. If you are added to the client's dev team and download their distribution certificate, you will NOT have this key and cannot sign distribution builds with associated provisioning profiles.
Therefore, you must either get a .p12 export of the certificate (which contains the key) from the client to install on your machine so that you may sign with it. This will allow you to submit from your machine, but you are then in possession of your clien'ts private key, which they would like to protect. Your other option is to use your own Certificate Signing Request to create a Distribution Certificate on the client's developer account. In this situation, only you have control over the certificate and the client must create new ones if they wish to work with other developers in the future.
Once you have done that, here is an informative guide for enterprise distribution.
As an Enterprise Agent I will tell you that unless your client lives under a rock (technically speaking regarding the Apple dev portal) I doubt they're going to give up the private key and cert. If they have zero legal/contractual access to the source code you've created the only course of action, speaking from experience, would be for you to visit their facility with the source code, compile it on their box that houses the private key & enterprise distribution cert, build & deliver the IPA and finally take the source back with you. That is how I have compiled every build with a 3rd party vendor where we don't own the source and need to deploy internally.
On the flip side of this argument if the client is, for some wild reason, willing to give up the keys to their enterprise castle and export the private key & enterprise distribution cert for you to use... for YOUR sake I would get in writing what the scope of your usage is with that cert and somehow document the fact you have deleted the key & cert after the process is over. Don't open yourself up to liability because if they share it with you there's a chance they may also share it with someone else and as we all know, not all development entities play by the rules. You wouldn't want to get accused of creating some rogue app under their name.
Regarding re-signing the IPA file... AirWatch won't let you do it. AW interrogates the IPA when you upload it and it will note that the embedded provisioning profile doesn't match the re-signed IPA and tank. It becomes a chicken & egg situation where you need the provisioning profile on the device before you install the app however AirWatch won't let you deploy the app unless the aforementioned embedded profile is correct.
Also, #Caleb is correct regarding B2B but the pricing model goes from the project to per-seat (iOS device). In other words if your contract is "you can install this app on an unlimited number of devices" the B2B approach is going to blow up in everyone's faces.
EDIT:
Below are your options when editing a Development Provisioning Profile in an Enterprise iOS Account:
Obviously here you can pick & choose developers and their devices from within the portal that can compile to that profile.
Now here are your "options" for editing the Enterprise Provisioning Profile:
As you can see you don't get an option to edit which portal users or devices can use this profile because it's tied to the Agent's CSR/private key and is deployed globally.
You would need:
Their certificate.
Their provisioning profile.
It's a quite common practise to do this.
My question is, is this the correct way to do this?
Yes.
What if I am going to sell this same app to 3 clients, would I do it a different way?
No, you'll do the same thing. You'll need to build the app separately for each client using each client's distribution certificate.
Another option is to build the app and sell it to your clients using the B2B distribution mechanism.
Here's my scenario. I work on a team of 3 developers. Currently I am the only one who does iphone development so at this point we have 1 project that I created, tested and then created a deployment certificate so I could build it and deploy it to a few devices. 1 developer, 1 app, it's all pretty straight forward. Here is where my problem lies.
Now lets say one of the other developers has to checkout the source code, make a change and redeploy, and I am not around, nor is the computer that I developed on. I have read everything I could find and I understand the other developer would need to download the distribution certificate and deployment provisioning profile and that I would also need to export the private key of the distribution certificate to the .p12 format for them to put on their machine. This all works as said.
The question I have and what I can't seem to figure out is that the distribution certificate I created is signed with my developer private key. I feel like that should not be the case because if I export this and give it to them they now have my private key which from what I can tell is something you are supposed to keep secret and in a safe place for me to develop on other machines or in case I need to reinstall, not something I would give to other developers just so they can deploy. And vice versa when they create an application and I need to make changes and deploy.
I have searched everywhere for an answer but I don't seem to be able to find the exact answer I need to understand what I am missing. Maybe I'm just missing some essential concept.
Is there a way to create a distribution profile with a private key of my company rather than myself? Or even a key that I can name for each project if I have to create a distribution certificate for each project.
Is sharing my personal private key attached to the distribution certificate wrong/bad?
What can they do with my private key? I feel like we should have a company private key or something.
I know this is long winded but I am really at a loss at this point. Here is another post that is similar and it also links to another post that was having the same problem that from what I can tell didn't get answered clearly, at least as far as I can tell.
Enabling multiple team admins to build an app for distribution in XCode 4.3?
Any help for how a team of developers can all build and deploy without sharing their private keys would be greatly appreciated. I assume it's simple because I can't imagine other companies are deploying from a single machine.
Jon
The answer (like the question) is somewhat longer:
1) As a rule, distribution provisioning profiles (Ad-Hoc, Enterprise InHouse and AppStore) are using different certificate/key pairs then development provisioning profiles. There are clearly marked as such in the provisioning portal (e.g. developer certificate, distribution certificate, and push certificate).
2) Companies tend to limit the access to distribution keys, as their leakage introduces significant security implications (e.g. someone could try to distribute your application with malware etc). A common practice is to have one to three designated "Signers"
3) As for one agains multiple distribution certificates: there is a limit on the number of distribution certificates you can have (I think it's two). Also, in case of distribution provisioning profiles, you are allowed to pick only one. So if you would like to use two keys/certs regularly, you would have to have two provisioning profiles for the same app. Trust me! xcode will make you regret this idea!
Bonus note: In theory it should be possible to create a CSR (certificate signing request) with a private/public key pair of your choice, instead of the default behaviour of generating a new one. More here
Your developer private key is not being used with the distribution certificate. There are two private keys involved with your scenario above.
Open Keychain Access, select your login keychain and select "My Certificates" under category.
1) Your developer private key should never need to be shared with another developer. It is unique and for your use only. Only if you are migrating to a new computer should you need to export this. In your Keychain Access application, you will see this certificate listed as "iPhone Developer: Your Name"
2) The distribution certificate has a separate private key. It is located on the computer that created the distribution certificate request and is in the Keychain Access application listed as "iPhone Distribution: Your Company Name". You will need to export this certificate (including both public and private keys) to allow someone else to create an enterprise distribution using the EXISTING provisioning profile. For information of how to export these keys, see: https://stackoverflow.com/a/9418712/600753
I recommend the above approach, but another alternative is to have the other developer create another distribution certificate and another provisioning profile. This approach has a tendency to confuse the auto selection of the provisioning profiles within Xcode and is usually more trouble than it's worth.