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.
Related
Quick sanity check - I've read through several related questions and I'm still confused about this topic.
I have build the app with a provisioning profile(in-house) with enterprise account.
That provisioning profile is getting expired in next few days and the distribution certificate used for that provisioning profile expires in next year.
If the provisioning profile gets expires will the apps which were distributed stops working or they will keep working as distribution cert is intact?
The answer is: MAYBE (but they will probably stop working)
So, the thing you need to realize is that, while your provisioning profile is installed with the app, at install time, it is simply added to the set of installed profiles on the device. When you go to run an app, iOS simply checks if there is a valid profile that works for the app. It doesn't have to be the one installed with the app.
So, let's say you have an enterprise provisioning profile that uses a wildcard app ID. You install your app (app A) with a provisioning profile that is set to expire on 4/12/2020. If that is the only enterprise app you have on the device, and you do not install a new provisioning profile through another means (like MDM - mobile device management), the app will not run on 4/13.
However, let's say your organization uses a wildcard id in their provisioning profile, and you (or another team) builds a second app (app B) that is installed afterwards, but it is installed with a provisioning profile that is set to expire on 1/1/2021. If that app is installed on the same device as app A, when the user launches app A, and it will check for a valid provisioning profile on the device, find the one installed with app B, and be allowed to run. This scenario is likely why #Shubham thinks that the app will continue to run - he has probably experienced this, but thought it was due to the certificate expiration. It definitely was NOT!
So, I would recommend you get a new provisioning profile installed on devices running those apps as soon as possible. The easiest way to do that is to create a new build of the app with the new provisioning profile and install the new version. If these are managed devices and your MDM software allows it, you could simply install a new provisioning profile directly.
But, whatever you do, don't believe that you don't need to worry about it because the certificate is still good. You need to get a newer profile on your devices or you will have a lot of apps that appear to crash on start up. Believe me, I've been there.
However, when you get close to the certificate expiring, you will definitely need to rebuild a new binary, so plan ahead for that. Pushing a new profile onto the device won't work then, because the binary on the device is signed with the cert, so the only way to fix an expired cert is to build a new binary signed by the new cert.
Your enterprise app needs to contain a valid provisioning profile. This means that it will need to be updated at least once every 12 months.
If your enterprise app is distributed by MDM then you can use your MDM to distribute a new provisioning profile without updating the entire app. A new app version will be required at least once every 2 years as the signing certificate will expire.
For more information refer to this 2014 WWDC session - Transcript
It was also covered briefly in this 2019 WWDC Session
I am currently 3 days from the expiration of 1 of my two allowed Apple Developer enterprise certificates; the provisioning profile for the app in question is also expiring on the same day. What I'm trying to figure out is what is the safest and cleanest way to renew the certificate, minimizing any time where existing builds would not be able to open or install from the Airwatch MDM catalog.
I have been able to find good information on AppStore certificates, in that it's totally fine if you revoke or allow the certificates to expire, the apps still continue to function, just no resigning of new versions. But the only relevant documentation I've been able to find mentions that on expiration, enterprise apps will stop functioning.
In the process of determining the best path, we did revoke our 2nd certificate and regenerated it - the revoke immediately broke the application that was using it and it was no longer able to be downloaded or opened. This causes us pause when considering revoking the 1st certificate prior to it expiring.
Any help would be amazing; sorry if this seems off-topic as I have seen marked on other questions on the topic.
[Updated after the profile replacement scenario ended up failing once the original cert and profile expired]
No great answers here (talked with Apple support for a while), but it actually worked fine.
Learnings:
Works:
- Multiple computers can sign using the same cert via sharing the private key using export/import from keychain or xcode (could be used in scenarios where multiple teams need to sign for the same enterprise account)
Doesn't Work:
- (what we tried, failed) Just uploading a new provisioning profile (based on a new/2nd cert) to existing apps in Airwatch (or other MDM or doing some of the re-sign, replace profile scripts that are out there) seems to keep them alive no problem. Then you can regenerate your expiring cert once the deadline passes, then resign back to the proper cert sometime in the 3 years until other cert expires
We have multiple applications custom build for specific clients. Each application has its own "Enterprise" Distribution Certificate "iOS UniversalDistribution". Today we received word that all our client's applications have stopped working, they won't even open. At first we thought it was a bug after an update, but we noticed that our Provisioning profiles have expired. We did not receive any warnings, notifications, emails, ... they all just stopped working.
The applications are able to update themselves with a custom service we've build. Now that they won't open on the devices we fear we have to manually install the new versions on the devices?
But this means that in the future this WILL happen again. After researching the apple documentation something is still not clear. If we build a new version of the application (.IPA file) and we push the updates in the app, will the application also update all the certificates accordingly? So if we do an update several weeks before with renewed provisioning profiles will it prevent this from happening again?
Thanks in advance for the feedback.
So, unfortunately, none of the existing deployed apps will run now, so you will not be able to use the self-updating logic in the app to correct this. This is up to the developers to keep track of expiring profiles and certificates and ensure they get updated as needed.
All of the information below assumes you are using an Enterprise Distribution Profile to build these iOS apps.
You should note is that there are two things that can expire: the provisioning profile and the certificate.
Expiring Provisioning Profile:
Typically the provisioning profile expiring is easier to deal with, as you only need to get a new profile on the device. Technically, doing a new build with a new provisioning profile will do this, but there are other ways. For example, if these are managed, company devices, you can typically use the MDM software to push a new profile to the devices, without requiring a new .ipa (app binary) to be installed on the device). Also, if you use wildcard app ids in your provisioning profile, installing another device with a newer provisioning profile will also work (although this is a bit unorthodox). Long story, short: You need to get the new profile on the device. At this point, that is likely through you informing users they need to go re-download a new version of the app.
Expiring Certificate
If the certificate used to code sign the application is expiring, you will need to generate a new binary with the new certificate. There are ways to resign an existing ipa, but if you have the source code, it is easier to just re-build with the new certificate. The good news is that the certificate only expires every 3 years for an enterprise distribution certificate (vs. every 1 year for the provisioning profile). So this is not needed as often. But this will certainly require you to re-create a new binary signed with the new certificate.
Preventing This From Recurring
If you rely on the app to check for updates and self update, you need to make sure a new version gets published well enough in advance that users will launch the app in the time between the new version being released, and the profile or cert expiration. This length of time depends on your app. If it's a corporate app that people use daily, you can probably get by with 2 or 3 weeks (for people who are out of the office). If it's seldom used, I would consider deploying a new version, with a new provisioning profile at least 3-6 months in advance of the old one expiring. This takes planning and reminders to ensure you don't miss the timing window.
Also of note, if you are using automatic code signing, you lose some control over when a new profile is generated and used, as well as the certificates. That's why I recommend for enterprise apps to use manual code signing settings to allow you to be very explicit with which provisioning profiles are used, as well as the cert. Also, delete all older profiles from the Mac when doing a build to ensure you are using the right profile (you can have many profiles on the Mac for the same application at any given time. You can find them here: https://stackoverflow.com/a/45642752/3708242). It's risky to assume Xcode will pick the most recent one.
Context: A provisioning profile(PP) is nearly expired. The distribution certificate linked to it, will not expire for the next 2 years. The corresponding app is distributed over a MDM. All i read about renewing a PP is also including renewing the distribution certificate. But i just want to extend the PP with as little effort as possible.
Approaches: Either i would just press the "Generate" (on apple developer site while editing the PP) without changing anything or i would create a new one besides this one with same settings.
Questions: Which approach do you recommend? Is there a way, that i don't have to reinstall the app? What happens if i update this PP? Will the app run until the old PP is expired and then i have to install the new app with new PP?
I'd appreciate your input.
Yes, if the certificate is still good for a while, the best approach is to simply generate a new provisioning profile. Your existing deployments of the app will not be affected (as long as you don't revoke the certificate) because the existing profile is technically still valid until it expires.
Then, before the old profile expires, you have two options.
You can re-build the app with the new provisioning profile and push to the devices with your MDM solution. This will install the app AND the new provisioning profile on the devices. The app doesn't need to have changed - you are just using it to carry the payload of the new provisioning profile. The app will then work until the new provisioning profile expires (and you'll repeat this process next year).
If your MDM solution offers the ability to push the provisioning profile to your devices directly, take your new provisioning profile and deploy it to all the devices with the app. Once you have done this, the app will continue to run after the original, embedded provisioning profile has expired, because all iOS cares about is if there is a valid provisioning profile for the app ID on the device. No need to re-build the app, so this is preferable if there is no other reason to update the app.
Note that when your certificate expires, however, you will need to rebuild (or at least re-sign) the apps and redeploy them to the devices, so there will be no easy fix of just pushing a new provisioning profile when that happens. Plan ahead and give yourself enough time before the cert expires to make sure all necessary apps are re-built and redeployed.
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.