I have a client who forgot to pay for their enterprise account and therefore their apps stopped working, as expected.
However, one would think that it should be sufficient to just start paying again to be able to use the apps as before. But as it seems, all certificates in the apple developer portal are now deleted?!
Is this expected behaviour or will they show up after some time again?
As it is now, we will have to rebuild all apps again with new distribution certificates. Is this the solution?
Short answer to your question:
I wouldn't expect the certs to automatically reappear. I recommend opening a support incident with Apple. Since the account was recently renewed, you should have two incidents available.
There's this section of the App Distribution Guide which talks about re-creating deleted certificates but I'm guessing it's more geared toward iTunes distributed apps and circumstances where certificates (private keys) are deleted but not revoked at Apple's CA.
Instead of recompiling your apps, you might be able to instead push out updated Provisioning Profiles and Certs. See below for more details.
Additional info:
It makes sense that Apple would revoke Enterprise certs upon membership expiration since that's the only way they could force apps to stop working. Since Enterprise apps stop working when either the Provisioning Profile or the Certificate expire, Appple can't push out an expired Provisioning Profile, and there's no in-app check for a Profile either (which is why if you delete your Profile in the developer portal, it won't affect any already downloaded/installed apps), which leaves the only other option: revoke the certs. The affected apps stop working once they sync with Apple's CA. Devices without connectivity will continue working until the Profile expires.
It may be possible to remove your certs from the Certificate Revocation List (CRL) but Apple support would be your only likely resource to help with this.
If you're out of options for re-enabling your old certs, you can update the Provisioning Profiles (and I think Certs) and push that out without recompiling all your apps. Also, if you use wildcard App IDs, an update to one app Provisioning Profile will apply to all installed apps that share that App ID.
If your users' devices are managed via MDM, it's possible to push updated provisioning profiles via MDM, and according to this post, via Device Enrollment Program (DEP). I thought I read a while back that you could also update provisioning profiles from a desktop/laptop to a connected device using iTunes - not sure where that is now. I don't know if it's possible to direct users to a link to update the Profile OTA like they would install an app.
I hope this helps in some way. Please let us know what happens - I fear the same could happen to me, whether a cert is deleted by Apple or a haphazard developer.
Related
Forward: There are many similar SO questions with regard to this error. I've visited dozens of them over the past days, but none seem to have a solution to my problem. They mostly are from developers with full admin rights, unlike myself. Most solutions are also hacks or unclear.
I am a member of a developer team at Apple's developer.apple.com site. I've been charged with uploaded an iOS application I've developed to iTunesConnect, in order to be able to deploy it with TestFlight.
In order to successfully accomplish this. I asked for the following to be done.
That I be added as a member developer. See certificates here.
A matching App with the same bundle-ID be created for me on iTunesConnect.
A Distribution provisioning profile be added at developer.apple.com for my specific App.
Despite all of this. When I try to validate the app, I'm met with the following message.
It would appear from a manual signing attempt that because the provisioning profile was created by a team administrator, that I cannot sign it without their private key. Assuming this is correct, then how can any developer ever distribute apps if:
A distribution provisioning profile requires you be the creator in order to be validated.
Only a team admin can create a distribution provisioning profile.
This appears to be a paradox.
What can be done to resolve this conflict? I am only a member of this development team temporarily, and would like to formulate a clear solution to this problem so that I do not test their patience with repeated troubleshooting questions. To make it easier to answer this question, I've attached some extra images that might be useful.
My app's general panel in Xcode when using automatic signing. It shows I am signing on behalf of the team.
Solving this problem required two steps.
A certificate signing request (CSR) was created and sent to the developer who had created the distribution provisioning profile. You can create a CSR by going to: Keychain Access > Certificate Assistant > Request a Certificate from a Certificate Authority. Once I received this CSR back from the developer, I double clicked it to install it in my keychain. It then appeared as so:
Next, the developer had to add the certificate they sent me to the provisioning profile for the app on developer.apple.com. I then downloaded this provisioning profile again and selected it in within Xcode as seen below.
Once this is completed, you should be able to validate the application.
I got this error when my ExportOptions.plist file had the wrong value for the method. I had "enterprise" rather than "ad-hoc". (This is the file passed to xcodebuild via the -exportOptionsPlist option.)
As a developer of an app it could be quite a turn off if half of your users cannot open your app because they get following error.
[i know there is a workaround by going to sys preferences->security-> allow apps from "anywhere" but users of our apps are kids, they may not be in the best position to know how to do that]
What things I need to take care of in oder to avoid this warning, or to get apple developer identity?
This app has been published on App Store, so all the provisioning profiles and certificates are there. Now we want to put the app on our website, but before doing that we want to eliminate this gatekeeper hurdle.
In the screenshot above you can see that the right developer is selected while archiving.
The signing identity used for App Store submissions and for independent publishing are different. The latter requires a Developer ID identity be used. See Distributing Applications Outside the Mac App Store for more information about the process.
My Ad Hoc profile is about to expire in 14 days. There is a a "renew" button for my ad hoc profile in the organizer but when I click it I get...
There are no current certificates on this team matching the provided certificate IDs.
The profile in the provisioning portal shows active, expiring on the 30th. I also see a distribution certificate with the same expiration date. I must assume that this certificate is the one that was used to sign the profile. Is there any way to fix this without revoking and creating a new ad hoc profile and certificate?
If I have to start over, what is the best way to proceed without messing up my testors.
There are a lot of posts and answers on this subject but I can't find any that address this particular problem with the certificate not matching the certificat ID of the profile.
Ad-Hoc Provisioning Profiles are composed of three main elements:
Exactly 1 AppID
The Public Key of your Distribution Certificate
One or more Registered Test Device IDs
When you first generated this Provisioning Profile (about a year ago if your current one is expiring soon!), you instructed it to use your then current Distribution Certificate when constructing that provisioning profile -- the resulting Ad-Hoc Profile's expiration date is set to match the expiration of the Distribution Certificate as you can't launch an app signed with an expired certificate (Aside: This doesn't necessarily apply in Jailbroken scenarios...)
Your main question of 'Can it be fixed without revoking?' is a solid 'No' -- Even if you could make adjustments, the soon-expiring Distribution Certificate would cause the newly reissued Ad-Hoc Profile to have an expiry matching that of the Distribution Certificate. You'll be back in this same situation in 14 days when both your certificate and Provisioning Profile have both expired. Unfortunately at that time you'll also have a new problem, any existing builds you have out to your testers will no longer launch as the signing certificate and provisioning profile will have lapsed.
Instead, these last two weeks are your opportunity to be proactive and get your users migrated to a new build with a new Certificate and Provisioning Profile. With my own testers, I treat the last few weeks of my current Distribution Certificate as a migration window to get builds switched over and get my testers to download and install the latest test build so that they can keep going with their testing. The great news is that you caught your certificates expiring with more than enough time to get things straightened out and get your testers migrated -- some aren't so lucky and have to play catchup after things have expired and have testers shouting about your app crashing/no longer launching...definitely an undesirable outcome for any developer, especially if you are a one-person shop and having to coordinate both development and beta tester communications yourself.
So what do I have to do?
At a high level, doing the migration is nearly identical to getting this Ad-Hoc profile setup the first time -- It just requires cleaning up the old data from your Keychain and Provisioning Profiles as well as sending out some tester emails encouraging your team to upgrade once you make a new build available to them. At a high level this process looks like this:
Revoke your existing Distribution Certificate and reissue a new Distribution Certificate.
Delete the existing Distribution Certificate from your Keychain and install the new one.
Update and install the now 'Invalid' Ad-Hoc profile to use your newly created Distribution Certificate
Update Code Sign Build Settings if necessary.
Construct and issue your Ad-Hoc build to your testers.
Wait -- Won't revoking my existing certificate disrupt my testers?
Nope, not in the least bit! Your existing Ad-Hoc builds will continue to work perfectly well until after the expiration date because they have all the information they need to verify code signatures right inside the Ad-Hoc build you've already sent them. Once the certificate expires, however then things will fail to launch and you'll have screaming testers on your hands.
I'm going to assume that you are using an Individual account, so certificates will appear in the format "iPhone Developer: FirstName LastName" and "iPhone Distribution: FirstName LastName". If you are using a Company Account, then the format will be slightly different. I'm also going to assume that you only have your one account; if you are enrolled in multiple developer accounts, take extra care when searching for and deleting your existing certificates and profiles from Keychain as there may be multiple similar entries.
To begin, quit out of Xcode and then head over to developer.apple.com/ios login to the "Certificates, Identifiers & Profiles" area. This is formerly known as the "Provisioning Center".
Revoking and Reissuing the Distribution Certificate
Navigate to the Distribution Certificates Area.
Locate your soon-to-expire Distribution Certificate and revoke it. You'll likely encounter a message informing you that revoking this certificate will invalidate any linked provisioning profiles -- that is entirely expected and OK. In fact, that is exactly what we want it to do so that you can get things updated!
Click the 'Add' button in the upper right corner and walk through the steps to make a new "App Store and Ad Hoc" Distribution Certificate. Download the file to your machine, but don't install it just yet -- we should clean up the old certificate from your Development Machine first.
Deleting the Revoked Certificate and Installing the New Certificate
Open Keychain Access and search for 'iPhone Distribution'.
Delete any blue certificates that match 'iPhone Distribution'. The certificate icon may also show a red 'X' indicating that it is either expired or revoked. These may be cleaned up as well as they are no longer of use.
Double-click the newly downloaded certificate and install it.
Edit the Ad-Hoc Provisioning Profiles
Navigate to the Distribution Provisioning Profiles section and locate your Ad-Hoc Profile.
Edit that profile updating the test device list if necessary.
Click Generate and download the newly created Provisioning Profile. If the Generate button is disabled check that there are no special characters in the Provisioning Profile's name and that you've selected at least one test device.
Drag and drop the newly downloaded provisioning profile on to Xcode. Any old versions of the profile may be deleted from Organizer.
At this point you should be back in business and ready to update Code Sign settings if necessary (that is, if you set them to match a specific profile instead of using the Automatic Profile Selector option you'll need to update that setting to point to the now current version of your Provisioning Profile).
Again, you are fortunate in that you are taking steps to get this issue fixed while you testers are still able to use your app and not having to rush or hurry to get this done. Take your time and make sure to cleanup the older certificates and expiring provisioning profiles to make it easier for Xcode to figure out that you want it to use the newest profile.
I've done codesigning and submitting for iOS apps countless times. This time it struck me with the Mac App Store. I'm repeatedly getting the same error message:
"My Name" is a valid identity. However,
you do not have the associated package identity.
I've recognized this 2 topics here on stack overflow:
mas-code-signing-identity-private-key and mac-app-package-identity-not-installed
Nothing inside there solved the problem for me.
Thats how I (most reliably) reproduce this message:
I clean up all my certificates and private keys starting with "Mac Developer" or "3rd Party Mac Developer". Of course also the expired ones.
Revoking all the stuff inside the Mac certification portal.
Create App-ID (did it only once)
Create new certificate for Mac Development. I can only assume that this is comparable to the debugging certificates for iOS development.
Create new certificate for Mac App. Once again I can only assume that this could be something similar to a distribution certificate in iOS-development.
For completion reasons create a new certificate/profile for my system.
Create a production provisioning profile. I can only assume that this might be equivalent to an iOS distribution profile.
I then download all the certificate mess and install it properly. Some go into the Keychain, others got into the Preferences and XCode.
For making sure I restart XCode or even the whole Mac (doesn't change the frustrating outcome anyway).
I go to the project build settings and select the production provisioning profile, because I assume "production" is equivalent to "distribution". Changing the codesigning identity in the target build settings doesn't work either. While Apple claims in it's documentation that for App Store submission the signing identity has to be changed in the project build settings.
I run an archive build.
I select the archive in the organizer and click validate.
This error message appears:
"My Name" is a valid identity. However,
you do not have the associated package identity.
I can't find any pointer to what the term "package identity" actually means. What is most frustrating to me is that this terminology mess in Apples documentation concerning the code signing and submission process appears not very clear and precise to me. At least not as clear and precise as the documentation for the same process concerning iOS App submission (which is using completely different terminology).
Probably I understood something wrong? Thanx for any help or pointer in advance.
OK, I have some important pointers (additional to Apples documentation) for people stumbling over similar issues.
The error message is totally misleading.
Don't take every word in Apples documentation too seriously.
For solving the issue, 2 points have been most significant:
Additional to all the other profile-mess you need 2 certificates for submission to the Mac App Store (contrary to the same process for iOS App Store submission). Both have to be installed together with their corresponding public and private key pairs.
Mac App
Mac Installer
The codesigning needs to be set on the build target, not the project. I don't remember where but this was described wrong side around in one of Apples documentations.
Eventually my submission worked by keeping to those 2 points.
There is an additional issue with Keychain & XCode.
When Xcode uses a certificate, they want one and only one certificate in your keychain. If you have an expired one, as well as a valid one, Xcode often fails the operation.
So you look at your keychain using Keychain Access, and do not see an expired certificate. It is still there! The default setting for Keychain Access hides expired certificates. Goto the View menu and select Show Expired Certificates. Delete all the expired ones, they are not good for anything.
Quit Keychain Acces and Relaunch Xcode. Xcode often requires a relaunch when adding/deleting certificates.
At that point, the Archive Validate process worked for me.
This is what it was for me as well.
Just want to clarify, you absolutely need both Mac App Distribution and Mac Installer Distribution certificates. Thanks Jacque for your explanation above. It should look like this:
Yes the problem is Mac Installer Distribution certificate.
The easiest way to have everything fixed and loose all the troubles just go to Xcode->Window->Organizer->Devices and then on the lower right corner press on Refresh and log in with your account... xcode will generate and download all the certificates and provisioning profiles needed.
I have an app that I'm going to put in the Mac App Store. I'd like to add iCloud support for preference syncing, and for that reason, I'd like to distribute the betas signed in such a way that they can access iCloud.
However, I haven't been able to find anything in the Mac documentation library about distributing an app, signed with a distribution key, outside of the App Store, and being able to access iCloud.
So far, my attempts to distribute such an application have met inability to launch on testers' machines, with messages in the Console complaining about the app having the iCloud entitlement.
Is what I'm after possible, or should I abandon iCloud support? If it is possible, what do I need to do to make a distributable, iCloud-capable build?
Edit: To be clear, you can replace “iCloud support” in this question with any other feature that is only available to App Store apps. I mention it to establish that the solution is not “just distribute it unsigned”. iCloud is the goal in my specific case; I'm asking about the general process.
You would need to gather the UUID for the tester's mac, either available via Xcode's Organizer or you can also access it via Apple System Profiler under the hardware overview. After adding it to the developer portal you'd generate a provisioning profile.
In order for them to actually run the application they would need to make use of an iTunes Connect test user account. This is one of two types of accounts that you can create in iTunes Connect, the other being an account with privileges (financial/technical/etc) for your developer membership. The test user account is needed in order for a receipt to be generated and the application actually run. Though you might be able to sidestep the test user account requirement by not actually validating receipts at that phase of development.
If you want to do iCloud or Push you need the UUID.
If you want to test a MAS app that doesn't need iCloud or Push, but does do receipt validation you need only the test user account.
My iCloud Mac app is stil in development, so I didn't try yet. But isn't it possible to sign the app with an entitlement and add a test user to iTC. In the OS X provisioning portal you can already add devices, and you need to add the testers Macs there and re-create the provisioning profile afterwards. After build & archive you "Share..." the app as installer or .app. The user needs to login with the/his test user you created in iTC on her/his Mac.