Enterprise In House Certificate Life Extended!
UPDATE: It turns out that this expiration extension does not actually extend the life-time of individual distribution profiles. Please see the comments below this article for more details.
I discovered this today and figured it was worth sharing with the Enterprise iOS community because it has such a profound impact on Enterprise app deployment strategies...
If you have ever dealt with iOS Enterprise In House distribution, you have undoubtably had to deal with the dreaded "Provisioning Profile Is About To Expire" message that appears on user devices every day for 30 days until the expiring profile is removed or the expiration date lapses.
I was pleased to find out today that Apple has changed the life of the underlying iOS Enterprise Distribution Certificate expiration date from one year to three years! 
This means you only have to deal with this (nightmare) every three years instead of every one year.
Practically speaking, this means the recommended enterprise app update lifecycle (in which you have users update their apps and/or remove the old provisioning profile) changes from six months to 1.5 years; a much more reasonable timeframe.
It appears that Apple made this change at the beginning of 2013 or late 2012; either way it seems like this change has been made across all enterprise iOS Developer accounts.
- Login or register to post comments
Post to Twitter
Share your ideas
MWYada
But there may be a catch...
I was likewise overjoyed when I saw this.
True, the Enterprise Distribution Certificate expires after 3 years, but unfortunately, individual app Distribution Provisioning Profiles seem to still expire after 1 year. Which means we still have to update all our apps 2x a year.
Unless I'm missing something.
mattvlasach
Anndddd you are right
You are 100% correct; I totally overlooked that the provisioning profile expiration is not tied to the distribution certificate expiration.
This ultimately means that the extension of the distribution certificate really only serves developers from having to deal with keychain stuff every year, but end users – and IT – are still stuck with annual app refreshes. * sigh *
Great catch though and thanks for replying. I will update the original post to reflect the correction.
kjlevers
Not exactly...
You may opt to only deploy the provisioning profiles for the yearly expiration rather than the entire app; still a pain, but not as bad.
From Apple's documentation: http://developer.apple.com/library/ios/#featuredarticles/FA_Wireless_Ent...
"Before to a provisioning profile expires, use the iOS Development Portal to create a new profile for the app. Create a new app archive (.ipa) with the new provisioning profile, for users who are installing the app for the first time.
For users who already have the app, you may want to time your next released version so that it includes the new provisioning profile. If not, you can distribute just the new .mobileprovision file so users won’t have to install the app again. The new provisioning profile will override the one that’s already in the app archive."
mattvlasach
I've seen otherwise (?)
From my past experiences, creating a new Provisioning Profile (with the same App ID and etc.) does not replace the expiring one when the new IPA/.mobileprovision is installed on the device (although Apple's documentation does say otherwise).
Instead, the old one is left there and must be removed by the user before it expires. Having had a discussion with an Apple engineer about this, they indicated that there is no way to effectively update or replace a provisioning profile without the user removing it. (Note: this is NOT the case with managed applications in which the app and provisioning profile were installed via push).
Is it possible this is not the case so long as you use the same distribution certificate (namely the new provisioning profile replaces the old one on the device)?
If so, I'd love to hear how you managed to get around this as we are on the brink of having to deal with this for another customer.
kjlevers
I am not sure yet
I haven't tried it in practice, but am planning to shortly. I would like to think that our MDM will be able to replace the expiring profile with a new one, but I have yet to test. I'm not exactly sure what you mean by installed via a push. In our scenario, the user still has to actively choose to download the app via the MDM interface and the profile comes down as well.
mattvlasach
Push vs. Pull App Install
I have spent a lot of time on this (in practice) pulling my hair out trying to understand all the little subtleties involved with App distribution and in-house provisioning profiles. It is beyond frustrating because there is very little (any?) documentation from Apple about the details involved with the provisioning profile lifecycle.
From what I have found, your best bet is to push apps (via Managed Applications) because your MDM platform CAN update apps AND can REPLACE corresponding provisioning profile. This is because the MDM daemon (for lack of the actual name) owns that installation (and can therefore manage it). When you have a new provisioning profile for an app, the MDM daemon is able to REMOVE the old one, then INSTALL the new one. Of important note, it does not UPDATE the old provisioning profile.
Conversely, if your users pull applications (from an appstore, web site link, etc.) the user owns the installation, therefore the MDM daemon CANNOT replace or remove the provisioning profile that was installed at app installation time. In this situation, the user must manually remove the provisioning profile before it expires. From what I have found nothing can overwrite/update/replace the expiring profile if it was installed by the user.
The caveat of this is that if the App's Provisioning Profile has been pushed to the device via MDM before the user performs the "pull" app installation. In this case, the MDM platform still "owns" the provisioning profile (the app installation process skips the re-installation of the provisioning profile) so MDM can remove it when an update comes along.
I think the fundamental reason for all of this headache is because the iOS Provisioning Portal does not provide the ability to UPDATE an already created provisioning profile (if someone has found a way to do this, PLEASE let me know!). You can create a new one with the same App ID, but there is no way to update an already created profile. This translates to the iOS device seeing those "updated" provisioning profiles as new provisioning profiles, installing them along side the old one. Ultimately I believe this is due to the fact that provisioning profiles are uniquely identified by attributes besides the signing certificate and app ID (I believe a UUID that is generated when the provisioning profile is created in the iOS Provisioning Portal).
If anyone has had practical experiences that differ from this, please don't hesitate to share them.
tomcrinny
Replacing provisioning profile via MDM
Hi All
We're going through the same pain at the moment.
Brief background:
- All our internal apps have been pushed to users' devices via an MDM tool (one of the market leaders)
- Users are currently receiving popups telling them that their provisioning profiles are due to expire (as expected)
Steps we have taken:
- Pushed new versions of the applications, with new provisioning profiles including our new enterprise distribution certificate
Result:
- A new provisioning profile has been installed on the devices, but the expiring profile has NOT been removed from the device
@mattvlasach - have you ever seen a provisioning profile successfully "updated" when using MDM push? I've raised a support ticket with Apple around this and they say that MDM should be able to do this. Our MDM vendor tells us that the provisioning profile has nothing to do with them.
It appears to me that there is no way to remotely 'update' a provisioning profile that is due to expire - despite what is says in some of the Apple documentation.
mattvlasach
Welcome to the club!
Ya, you are running into the exact problem I have come across and had to deal with.
In short, there is no way to update a provisioning profile, such that the old one is updated in place or otherwise seamlessly replaced.
I have done limited testing with MDM App Push to fully understand and advise on the way that MDM Managed Applications handle provisioning profiles.
That said, the method that I have seen work is the following:
I would recommend testing all of this by basically creating a provisioning profile and compiling an app with it, then creating a second provisioning profile (with a different name, same certificate is OK) and seeing if you can make MDM replace the old one per the above instructions using your MDM platform.
Please share your findings, thanks and good luck!
Best,
Matt
tomcrinny
Testing
Thanks Matt - I've seen a similar piece of advice to the approach you suggested above so I've asked our service partner to help us test it next week.
I'll post back here with how we get on. I'm hoping it'll give us a best practice approach for the future, as we've got a relatively dispersed workforce, and expiring profiles have the potential to cause a lot of help desk calls!
Tom