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
Related
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.
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.
First of all, sorry for my bad grammar!
I have this question and hope somebody can help me.
I work in a Mexican enterprise, we develop in house apps for sales, etc. and currently we started developing our apps in Swift.
Well, the point is that our Distribution Certificate where created in 2013 and the IPAs generated with it crashes when installed in a device.
Lurking about the problem, found that we have to re-create the Distribution Certificate and Provisioning Profiles for getting the Swift apps to work, but doing so, all the already distributed apps will crash sooner or later because of the change in the certs.
The question is:
Are we doomed to re-create all the provisioning profiles for all the existing apps in Obj-C, archive and re-distribute them again? or is there another way to get the old apps and the new ones to work simultaneously (like creating another Dist Cert and sign the new Swift apps with it), for I know, Apple is giving the chance to create a second Dist Cert along with the old one, but as far as I understood, it's just a support to re-distribute the apps when Dist Certs expire and not a long-term solution for a problem like this.
I really appreciate any help you can provide.
Every provisioning profile and certificate will expire one day, from that day on those apps will not launch any longer. You can see the end-date in the Apple portal where you created those.
There is no other way than to create a new certificate and profile and either re-sign the existing app with the new profile and certificate, or build the app with the new ones.
The company i work for have a few iOS apps distributed through the Enterprise program. We dont update these apps very frequently. So making sure that the certificates and provisioning profiles dont expire until we've had the chance to renew and redistribute the apps can be easy to forget. How does your team ensure this doesn't happen?
There's really not much you can do to prevent this, other than trying to keep all your apps being created with the same certificate / profiles, as up to date as possible. I have yet to find a good automated solution.
To manage it, I think the best solution is to create a reminder each time you generate a new certificate that will remind you in 11.5 months to renew the certificate (using the original cert signing request file). Then generate your certificate and new provisioning profile to be distributed to the developers (either by hand or by having them all signed into their Apple developer accounts as team members).
Once you have your new certificate and profiles, you'll need to regenerate the IPAs through xCode, or simply re-sign the ipa using the instructions found here: https://stackoverflow.com/a/25656455/3708242
For our internal apps using our enterprise distribution profile, we have put in self-update logic that allows us to push updates so that the users won't end up with an app that won't launch due to an expired provisioning profile or certificate.
Although I know many developer frown upon the use of wildcard ids in provisioning profiles, they do have one advantage here. If you have one app that is on all the devices, you could potentially get by with only updating that one app, as long as the new app has a provisioning profile and certificate that are not expired, and the provisioning profile has a wildcard id that matches all the internal apps you have. Once the valid profile is on the device, it will allow older apps to run. For more details about what I am talking about, see this answer: https://stackoverflow.com/a/29121777/3708242