Enterprise In House Certificate Life Extended!

  • strict warning: Only variables should be passed by reference in /var/sites/e/enterpriseios.com/public_html/sites/all/modules/contrib/captcha/captcha.inc on line 61.
  • strict warning: Only variables should be passed by reference in /var/sites/e/enterpriseios.com/public_html/sites/all/modules/contrib/captcha/captcha.inc on line 61.
  • strict warning: Only variables should be passed by reference in /var/sites/e/enterpriseios.com/public_html/sites/all/modules/contrib/captcha/captcha.inc on line 61.
  • strict warning: Only variables should be passed by reference in /var/sites/e/enterpriseios.com/public_html/sites/all/modules/contrib/captcha/captcha.inc on line 61.
  • strict warning: Only variables should be passed by reference in /var/sites/e/enterpriseios.com/public_html/sites/all/modules/contrib/captcha/captcha.inc on line 61.
  • strict warning: Only variables should be passed by reference in /var/sites/e/enterpriseios.com/public_html/sites/all/modules/contrib/captcha/captcha.inc on line 61.
  • strict warning: Only variables should be passed by reference in /var/sites/e/enterpriseios.com/public_html/sites/all/modules/contrib/captcha/captcha.inc on line 61.
  • strict warning: Only variables should be passed by reference in /var/sites/e/enterpriseios.com/public_html/sites/all/modules/contrib/captcha/captcha.inc on line 61.
  • strict warning: Only variables should be passed by reference in /var/sites/e/enterpriseios.com/public_html/sites/all/modules/contrib/captcha/captcha.inc on line 61.
  • strict warning: Only variables should be passed by reference in /var/sites/e/enterpriseios.com/public_html/sites/all/modules/contrib/captcha/captcha.inc on line 61.
  • strict warning: Only variables should be passed by reference in /var/sites/e/enterpriseios.com/public_html/sites/all/modules/contrib/captcha/captcha.inc on line 61.
  • strict warning: Only variables should be passed by reference in /var/sites/e/enterpriseios.com/public_html/sites/all/modules/contrib/captcha/captcha.inc on line 61.
  • strict warning: Only variables should be passed by reference in /var/sites/e/enterpriseios.com/public_html/sites/all/modules/contrib/captcha/captcha.inc on line 61.
  • strict warning: Only variables should be passed by reference in /var/sites/e/enterpriseios.com/public_html/sites/all/modules/contrib/captcha/captcha.inc on line 61.
  • strict warning: Declaration of views_handler_field_user_name::init() should be compatible with views_handler_field_user::init(&$view, $data) in /var/sites/e/enterpriseios.com/public_html/sites/all/modules/contrib/views/modules/user/views_handler_field_user_name.inc on line 61.
Your rating: None (5 votes)

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! Laughing out loud

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.

Share your ideas

MWYada's picture

MWYada

Joined: Feb 4, 2013

But there may be a catch...

Your rating: None (2 votes)

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.

Top
mattvlasach's picture

mattvlasach

Joined: Jul 18, 2012
WWW

Anndddd you are right

Your rating: None

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.

Top
kjlevers's picture

kjlevers

Joined: Feb 6, 2013

Not exactly...

Your rating: None

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."

Top
mattvlasach's picture

mattvlasach

Joined: Jul 18, 2012
WWW

I've seen otherwise (?)

Your rating: None

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.

Top
kjlevers's picture

kjlevers

Joined: Feb 6, 2013

I am not sure yet

Your rating: None

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.

Top
mattvlasach's picture

mattvlasach

Joined: Jul 18, 2012
WWW

Push vs. Pull App Install

Your rating: None

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.

Top
tomcrinny's picture

tomcrinny

Joined: Feb 18, 2013

Replacing provisioning profile via MDM

Your rating: None

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.

Top
mattvlasach's picture

mattvlasach

Joined: Jul 18, 2012
WWW

Welcome to the club!

Your rating: None

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:

  1. Push the app's provisioning profile to the device via a MDM configuration policy
  2. Allow the user to download the app, or push it via MDM to the device. (It is important that the provisioning profile has already been installed successfully via MDM BEFORE the app is installed using either of these methods
  3. When it is time to update the app, update the provisioning profile in the MDM configuration policy you created in (1), or you can create a new one and push that to the device. The key point here is that the MDM server OWNS to provisioning profile installation, so it can REMOVE it through one of these operations
  4. Push the new version of the app out to the user / make them install. Again, make sure the new provisioning profile has been successfully delivered first, otherwise when the app is installed you will no longer have remote control of the provisioning profile.

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

Top
tomcrinny's picture

tomcrinny

Joined: Feb 18, 2013

Testing

Your rating: None

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

Top
seecoolguy's picture

seecoolguy

Joined: Oct 8, 2013

Matt, and others, I'm using

Your rating: None

Matt,
and others, I'm using Apple's Profile Manager as our MDM, I can deploy in-house apps and push out updates, but my older provisioning profile remains. Is there a way to push out the updated Provisioning file only using Apple's MDM?

Thanks,
Cisco

Top
PerBjoern's picture

PerBjoern

Joined: Oct 10, 2013
WWW

Provisioning profiles in Profile Manager

Your rating: None

Also looking into deploying Provisioning profiles using Profile Manager - with no luck Sad

PB Salling

Top
garv's picture

garv

Joined: Apr 18, 2014

Please Help

Your rating: None

My problem is that I have an enterprise app that is managed by MDM.Some of the users have installed the app from enterpise app store while some of the user have installed the app from Server Url(OTA).Recently the provisonal profile got expired so admin have updated the profile and send to all the users.The users recieved the profile and installed the new profile sucessfully.
But now the users who have installed the app from enterise app store are able to run the app but the users who have insatlled the app from Server Url(OTA) are not able to launch the app.
Please let me know why this happening?? I have cross verify the bundle id also.Everything is right.

Top
jriker1's picture

jriker1

Joined: Apr 29, 2014

Guessing this thread is a bit

Your rating: None

Guessing this thread is a bit dated however am in year two of my three year cert so am going to just update the provisioning profile. I'm not using an MDM. From history I know I can have the old profile installed (expires) and the new one (that usually gets installed with reinstalling the newly resigned app) and the app keeps working.

From this thread, it sounds like some are saying you need to delete the old profile from the iPad and then install the new one. Note I am using a wildcard profile so technically am just updating one profile and all apps associated should keep working. Do I need to ask everyone to delete the old profile and install the new one from a URL or can they just install the new profile and be done with it? I can't be sure as my profile hasn't expired and this is the first time not doing a full resign of all apps and can't find anything on the Apple site on how this works.

Thoughts?

Thanks.

JR

Top

Recent Activity