I've just renewed an iOS Enterprise certificate for a client and I've also created a new distribution profile against that certificate.
On the test devices there are apps installed that use the old certificate, which have also been trusted by the user, which is standard. The apps still work as the old certificate hasn't expired yet.
So far so good.
When a new app (using the new certificate / profile) is installed it asks the user to trust the Developer again :-(
If I go to Settings->General->Profiles & Device Management there are now 2 entries under 'ENTERPRISE APP' both with, what seems to be the same name. On closer inspection one says:
iPhone Distribution:MY COMPANY LTD/ (the old certificate, notice the trailing /)
and the other one is
iPhone Distribution:MY COMPANY LTD (but without the trailing /)
The App still works OK but it's very confusing to the end user. Has anyone any ideas why the trailing / is now missing? Is there a fix? It's not the end of the world but I'd like to be able to clean this up, if I can.
Thanks for any help/advice you can give.
Regards
Steve
I don't know why the name would have changed just from renewing the certificate - Apple probably just added some sort of filter to remove invalid characters, and that's why the / doesn't appear in the new one.
Unfortunately, there's probably nothing you can do about this. The Company Name field on the certificate comes from the name you provided when you signed up for your developer account, and they don't provide a way to change that (at least not through the web site - maybe try a call to support?)
The other apps that use the old certificate will stop working once the old cert expires, so they'll need to be rebuilt with the new credentials anyway - the confusion will go away at that point, so at least it's not permanent.
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 an in-house enterprise app that is managed (deployed) from MaaS360
'https://portal.fiberlink.com'
And this app is built (and still maintained) in XCode 4.6.3 (i know, i know), so I don't have any of the fancy new features in XCode 7 that might help alleviate this problem. In fact, even the refresh button in Organizer no longer works... you tap it and a dialog says "service unavailable" and I've tried it on different days, so it's not just a temporary glitch or service interruption. I believe apple disabled whatever portion of their service was servicing that request from XCode 4's Organizer.
The provisioning profile on it is going to expire in March, and I'm trying to figure out how to renew it without inconveniencing the users by making them download a new rebuilt app. It would be particularly painful for them because it would require they sync a few gigabytes of data from their device through iTunes for each person, and it's a few hundred people.
My problem is, my certificate I used to sign the app is also expiring around the same time (in March).
I happened to have another certificate and an associated provisioning profile, I had generated on a different mac which expires in 2019, and I tried to use it to update the expiring provisioning profile on MaaS360 for this app in question, and I get this error
So what has me a little terrified is, I'm back on the mac where I originally created and deployed the app... if I need to renew my existing certificate (which I assume means revoking it and replacing it with a new one), in order to create a new provisioning profile, aren't I going to run into this dialog again, claiming that my certificates don't match, because I'll now have a new one, hence I can't update the profile.
If the only way to update my expiring provisioning profile is with my soon-to-be-expired-but-also-identical certificate which originally created the profile, that still means my profile is going to expire as scheduled because my original certificate will have expired too.
Is there a way out of this dilemma?
You can have two certificates active at the same time. So I would generate a new certificate using the same key you used to generate the original one. To do this on the Apple developer portal, you will need the cert signing request. Most developers don't save this when they generate their certificate the first time. The good news is, if you have the private key that was used for your distribution certificate, you can use that to generate the CSR. To find out if you have the private key, you can use this post for how to locate it in the Keychain app. https://stackoverflow.com/a/33651921/3708242
Once you have verified that you have the private key used for the certificate for the app store distribution, you can generate the a CSR using the following procedure: https://stackoverflow.com/a/7111454/3708242
Once you have the CSR, go to Apple's developer portal and generate a new distribution certificate for "In-House and Ad Hoc" distribution. As long as you only have one out there, you should be able to create a second without having to revoke the existing one. Once you've done that, you will likely need to provide that certificate to the MaaS360 service (I'm not familiar with how that works, but somehow the Maas360 server must have the private key and certificate that the apps were built with, as it is clearly checking that when you push the build of your app and the certs don't match). So download the new cert and provide that to MaaS360.
Then, generate a new distribution profile using the new certificate. Or you can update the existing one to use the new cert by clicking the edit button on the provisioning profile, then changing the radio button to the new cert which should expire several years out. Note that this won't prevent any existing apps built using the profile from running in the meantime (revoking the certificate, however, would immediately cause the apps to stop working, which you don't want). Save and download the new profile, and use it to rebuild the app.
The app will then be built with the new certificate, that won't expire any time soon. I do think you are missing the part of the process where you will have to provide the new cert to MaaS360. I can't really help you with that part, but hopefully there is some documentation from IBM that can help you out there. But, you will need to fix it, because once the cert expires, non of the apps built with it will work. Good luck and let me know if any of this is not clear enough.
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.
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.
I work for a large, spread out (all over the country) company.
We have a paid iOS Dev Center account and I've been using it to develop iOS apps on phones for months now.
I've now returned to an iOS project after some weeks and it appears that while I was away the existing Development Certificate (the one you use to test and debug on phones, not the Distribution Certificate for the App Store) expired, and someone renewed it.
And now when I download that certificate, it doesn't match the private/public key pair on my system. My guess is that whoever did it generated a new key pair (whether or not they needed to do this I don't know).
So now I guess I need to hunt down the person who did this (it's in the name of the person who signed up for the account but that's not necessarily who did it) so I can get them to export their key pair.
Or I could revoke the certificate and make a new one.
If I do that, will it screw up anyone who's working with the (now revoked) certificate/key pair?
Anybody else who is developing with the new profile should also have the newly created new keys. so you don't necessarily have to hunt down the original person who revoked the old cert.
But if even that is problem then i suggest you revoke and send out the new .p12 to everybody who might need it. And as long as it does not affect the old apps (which it wont) you should be ok.
But on a sidenote your company needs a system to be able to do this efficiently.
I'm pretty sure - if you revoke his certificate, it will simply not be valid and clients will receive errors about unsigned / revoked signing on the app.