I am creating my apple developer certificates - just redoing them to have a clean up.
I can create both my developer and my distribution certificates fine, however they have a different name.
Will this affect the final product?
The reason I am doing a clean up is that it kept giving me errors about not matching certificates.
Any advice would be great:-)
Jeff
The distribution certificate have the name of your company and the developer certificate have your name.
You have to use distribution certificates to release program in app store or create ad-hoc program and the developer is only to compile and run in iPhone/iPad.
But, by nameyou are saying the identifier you can use the same for both certificates or create, like I do, 2 different, than the app store program will not overwrite your dev program.
Related
We are struggling with the Distribution Certificate handling from Apple.
We have several developers setup in the Apple Developer Portal, for the sake of the example:
Alice: Team Admin
Bob: Admin
Charles: Admin
Dan: Developer
Alice, Bob, and Charles should be able to build Apps for Distribution (Adhoc for internal testing, Testflight for external testing, and Appstore for distribution). Dan is only producing code and debugging on his local machine.
All users use individual accounts for the development.
From what we understood from the Apple documentation, Alice, Bob, Charles need a valid distribution certificate. If xCode generates it for them, they will start playing “ping pong”, and keep revoking each other’s certificate – at least this is what appears to be happening at the moment.
We are not sure why this would happen. One would think, that if you create a different new user this account can also maintain his own (distribution) certificates.
Anyway, so they will need to share a distribution certificate, by sharing the private key (p12 file) of it, as you can find in the answer here.
In our account, it appears as if we can have up to two valid distribution certificates.
We don’t really know how this ultimately worked – we didn’t do it manually over the developer portal, but used xCode for it. Alice generated her certificate, Bob revoked and regenerated, Alice did the same thing – but suddenly they both had a valid distribution certificate, instead of invalidating Bobs certificate.
In the documentation it was mentioned that you can have up to 2 valid distribution certificates. We have also manually tried to generate the distribution certificates and could confirm that it is limited to two.
However, we then got recently invited to a customer’s developer program to sign apps on his behalf.
I assume the customer was not aware that we require the private key from his distribution certificate. We therefore tried to manually generate a distribution certificate, and saw that it was not possible. To our surprise though, the customer managed to generate 3 valid distribution certificates.
Any idea how this worked?
Our questions in a nutshell:
1. What is best practice when you manage a team of developers?
Do you normally share the private key of the first developer who generated the certificate with all other team members, which should be able to sign the app?
2. What is the best practice when you work with clients?
Do you ask them to generate another private key, or is there some hidden functionality to generate as many distribution certificates as you want, given that every developer uses his own account?
3. What happens when we revoke a certificate.
It doesn’t affect the apps in the app store, but only seems to limit other developers to build their app. However, what happens with APNS / Push Server certificates? When we revoke a distribution certificate through xCode, will this also suddenly stop working for the sender?
Thank you for your help.
After a long time of investigation and trying things out, here is what we think is the best fit for us. Not sure if it is best practice but it seems to work for us just fine.
1. What is best practice when you manage a team of developers?
One person generates a distribution certificate using his mac. He then exports the certificate (public AND private key) in a p12 file, as suggested by washloops and shares it with the team.
2. What is the best practice when you work with clients?
We have two sorts of clients:
Clients working with multiple suppliers (so we are just taking care of 1 app, out of their portfolio) - We ask them to share their distribution certificate (public + private key). If they don't have it, they need to get it from another vendor.
Clients working only with us - We generate the certificate and share it with the client later on. This allows them to share it with other vendors if they need to.
3. What happens when we revoke a certificate.
From our tests: "nothing". If you revoke a distribution certificate, it will prevent developers using this certificate from submitting / building apps. However, existing APNS / Push certificates are not affected.
For us it seems as APNS / Push certificates are totally independent, and if you wish to revoke them, you need to revoke both.
You have to create just 1 distribution certificate. After that you go to Keychain Access, select the certificate and export it as ".p12", and maybe add a password to it.
After that you just install it in the other computers.
Regards :)
I have managed to get my Development and Distribution certificates in something of a mess (started with separate one for each App and more)
I'd like to start again with just one, generic, cert for each of Development and Distribution.
There are lots of tutorials on re-creating deleted or expired certificates but I can't find any confirmation that I can delete everything and start afresh (and, presumably, then use the new cert for new apps and/or updates to old ones?)
Has anyone actually gone through the steps of cancelling/deleting all Apple certificates and starting again? If so, any advice on steps and things to avoid will be appreciated.
thanks
Many thanks for the suggestions which I have now implemented.
I do now have just one each Development and Distribution certificate (although Xcode re-created the dozens of provisioning profiles I was trying to get rid of - I guess I will have to live with that long list for ever...).
An interesting result is the error message I received when I uploaded a new version of an App:
"Potential Loss of Keychain Access - The previous version of software has an application-identifier value of ['xxxxxxxxx.com.jeffmaynard.eurosceptic'] and the new version of software being submitted has an application-identifier of ['yyyyyyyyyy.com.jeffmaynard.eurosceptic']. This will result in a loss of keychain access."
Although the App has gone to review I am not sure of the consequences of this error message which I assume results from the certificate updates?
You have to clear your certificates in 2 places:
Keychain
Follow these steps to navigate and clear the certificates:
Open LaunchPad
Keychain Access
Select your Keychain
Select My Certificates
Now here you need to delete every certificate that starts with iPhone Developer or iPhone Distribution
Apple Developers Members Center
Login to Apple Developers
Go to Member Center
Click: Manage your certificates, App IDs, devices, and provisioning profiles
You have 2 tabs to interact Certificates and Provisioning Profiles
Remove all of them (Remember you can't delete those Provisioning Profiles, that are already in App Store).
Then you need to create it from the beginning: Follow my answer here
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.
I am in the following situation: We have an enterprise developer account and for an app we are working with an external developer.
At the moment we do not have access to the source code so we can't make builds, but we still need to have weekly builds that can be installed on devices... therefore the external developer needs to be able to build ipa files.
The developer is now a member of the developer program and has their own developer certificate. However, there can only be one distribution certificate.
From a security point of view, is it safe/recommended for us to share the distribution certificate (and the private key) and a provisioning profile so they can build ipa files?
Are there any other (safer) choices?
PS: I was also thinking that we could resign an ipa with our distribution certificate but it still leaves us in the situation where they need to be able to build an ipa - and this is only possible with a distribution certificate + provisioning installed.
You can have your external developer to sign with whatever he wants and then you can re-sign the IPA and use it. This way the source code is "safe" in the developer's perspective and you can use your IPA signed with your certificate. I normally use this, but you can do it in the command line too...
As for your Post Scriptum part, that's not true... I have the experience of working with external agencies where they use their own certificate and provisioning and when I receive their IPA I only need to re-signed it.
They can be responsible for creating their own profile, and you can simply send them your p12 key (no big deal). You can also just give them the distribution certificate.
To be honest, I've never been in a situation where an employer or contractor was hesitant to give me their certificate & p12 file. So I've never thought much of it!
I developed an iOS app that my client is going to use internally. They sent me their enterprise distribution provisioning profile. When I add it to XCode it says "Valid signing identity not found". How do I build the app so that my client can run it on their devices?
Your computer is unable to sign with the distribution profile, since you don't have the private key for this certificate.
Alternative 1
Apple intends that building a project for distribution will only take place on a single machine - the machine that the certificate was originally created on. So, in their eyes, you should ask your clients to build the project internally (for distribution only - for development you should have no problems building yourself).
Alternative 2
There is a way to override it.. and it involves exporting the private key from that special distribution machine and emailing it to you.
These are the steps (also outlined here):
Access the computer where the certificate was created, open the "Keychain Access" program on the computer
In "Category" panel, select "Certificates"
Find the correct distribution certificate and expand it
Highlight both the iPhone distribution certificate line and the private key line under it.
Right click and select "Export 2 items"
Save the .p12 file, choose a password that can share, you will need it to import this file later
Email the saved file to you
Once you import this and type in the password from step 6, you will have the private key on your computer too and all will be good.
Alternative 3
There's a chance that when you ask your clients to export the private key, they will have no idea what you're talking about and no idea where the machine that created it is (this is what actually happened to me). This is usually the case if they are not regularly building for distribution on their own.
In this case, you can simply delete the certificate and create a new one (for the distribution profile). If you create the certificate on your machine, then you will have the private key. You should also export it to them just in case (using the same steps of alternative 2).. so they have the ability to build without you if need be.
Each provisioning profile is paired with a certificate. If you subscribe to the Apple developer service, you should have access to create and download a development cert (tied to the apple ID) and a distribution cert (tied to the organization). The enterprise distribution provisioning profile needs to be paired with the distribution cert. So in order to use their provisioning profile, you will have to get the distribution certificate from them. This will also involve you getting their private key, which they might not be so fond of. Alternatively, they can set you up as a developer on their portal, then you can distribute through the machine that already has the distribution cert installed on it.