I have an IOS application for a client and I need to push it as an update to the existing app. I already received the credentials of the itunesconnect account which includes the application however here is my problem.
I don't have the private key which was used to publish the initial application which according to the below could cause a problem.
The private key is locally stored on the Mac device (in this case, the old vendor).
In the wrong hands, someone might attempt to distribute an app that contains malicious code.
Not only could that cause the app to be rejected, it could also mean our developer credentials could be revoked by Apple.
Is there a way to retrieve the old key?
In the case where I sign the application with another certificate, will still go as an update to the existing one?
Your fears are unfounded.
In the wrong hands, someone might attempt to distribute an app that
contains malicious code
Don't forget that they would also need your team agent's credential to submit the app. Even if they have the private key, they wouldn't be able to submit anything.
Is there a way to retrieve the old key?
No need to retrieve the old key, just revoke it from the provisioning portal and generate a new one.
In the case where I sign the application with another certificate,
will still go as an update to the existing one?
App updates are based upon bundle ID and not the code signing certificate. App submitted with the new certificate would still be considered an update, if the bundle ID is same.
Create new Distribution certificates and upload latest build with new version, this will go as update to users.
Related
I am working in project which is already in Appstore submitted by different developer. Now I am trying to submit updated version of the app with different version and build number. I can't able to access previously stored keychain values.
Here is the steps I did
Revoked the old Distribution certificate created by another person and created a new one with my machine.
Regenerated Provisioning Profile which is used by previous developers
Code signed and submitted to App Store
Downloading old build from App Store
Installing the updated build from test flight
Now I can't able to access keychain values already stored.
Now what can I do to retrieve the old keychain value? I have also checked the team ID for Keychain group access it is same as old one. Is there any way I can retrieve the old keychain values.
Here is brief answer which may help you to resolve your issue :
keychain group which is tied your team identifier. So, basically,
access to keychain after app updates depends on distribution
certificate you use, not on the provisioning profile
So if you are saying you revoke all old certificate and the one with the new certificate ( that you created ) that access to keychain groups will be lost for this version.
Finally I got a solution from apple guides
Note: In iOS, Keychain rights depend on the provisioning profile used
to sign your application. Be sure to consistently use the same
provisioning profile across different versions of your application.
https://developer.apple.com/library/content/documentation/Security/Conceptual/keychainServConcepts/iPhoneTasks/iPhoneTasks.html
Last week we've transferred a published app in iTunes Connect to another company's account. Now they want us to provide an update to the app.
How do we sign, package and submit the app to them for publishing? Which Provisioning profile do we need to use? Do we still sign the .ipa with our team and send the .ipa to them or do we need to have additional info for this to work?
I hope someone is able to shed some light on this process, since the whole provisioning and signing process is hard to grasp for me.
Recently we have transferred our app to another company and we have pushed an update to the app. Let me explain you how we did
Once you transfer the app to another company account, you will not
be able to use your old certificates for publishing any new update
for app.
Apple by default removes your certificates and appid from your
previous account.
Apple generates an app id for your app in transferred account.
You can use this app id and create new certificate for your app and
publish the app by using new account.
You have to get the certificate and the private keys used to signe the application.
You import the private keys on your computer and install the certificate.
Then get the corresponding profile, compile, sign and post.
The other solution is to regenerate a new certificat with the keys on your computer, a new provisionning profile.
Then sign the app with those new files.
The certificate and profile need to be created from the new account.
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.
I just got this warning when submit my app to app store, it is just warning, not error. This app was transferred from another developer account to my account before, so the prefix of the App ID is changed.. I think this should be unavoidable, but since I got this warning, what does it affect my app actually? What Keychain access would be lost?
Have you transferred the app from another developer account to your one? The previous provisioning ID will obviously be different.
UPDATE - For clarification
I have noticed that this answer is getting a lot of views so I will just edit it to include my further explanation from the comments below.
Basically the previous version of your application will NO longer be able to access keychain in order to save secure strings such as passwords (if it contains this functionality). This is because the distribution/provisioning profile it was signed with contains a different ID than the one you are using in your new distribution/provisioning profile because you have transferred your app from a previous account to your new one.
However any NEW versions of your app which are signed with the latest distribution/provisioning profile WILL be able to access keychain as normal in order to save secure data if they need this functionality because they are signed with a distribution/provisioning profile which contains the latest App ID for that app.
The warning informs you that your updated app will not be able to access items previously saved in the keychain. The old version of your app can still access and store items in the keychain, just like the new version. However the two versions cannot share information in the keychain.
In summary, all data saved in the keychain will be lost once a user updates to the new version. All information stored in UIPasteboard will also be lost.
You can see this message if:
The app was transferred to your account and you are updating it for the first time. In this case there is nothing you can do to prevent the warning (and side effects).
Your app was added to iTunes Connect before June 2011 and you recently updated the provisioning profile used by the app. Either your old provisioning profile was using a wildcard (*) App ID and the new one is now using a specific App ID, or the opposite (less likely). In the later case you can switch back and avoid the warning (choose the correct provisioning profile in Xcode). In the other case, chances are your app needs access to services like Game Center, Push Notifications (or anything that a wildcard App ID will not let you use) and you cannot avoid the warning.
If you want more details, the warning is related to the fact that App ID prefixes are attributed by Apple and cannot be changed. Check the "App IDs" section in Apple's "Certificate, Identifiers & Profiles" page (https://developer.apple.com/account/ios/identifiers/bundle/bundleList.action - you need to sign in), press on an ID and look at the "Prefix" field. You can also check Apple's Technical Note 2311 https://developer.apple.com/library/ios/technotes/tn2311/_index.html
Lastly, you might thing you could avoid the warning by changing the Keychain Access Groups (keychain-access-groups) field of your provisioning profile. This will not work as Apple will not let you have different prefixes for the App ID and for the Keychain Access Groups.
As of the stricter security in iOS 8.1.3, this is much more serious than the warning suggests; see https://developer.apple.com/library/ios/technotes/tn2319/_index.html#//apple_ref/doc/uid/DTS40013778-CH1-ERRORMESSAGES-UPGRADE_S_APPLICATION_IDENTIFIER_DOES_NOT_MATCH_THE_INSTALLED_APP. It seems like the mismatch causes a failure to upgrade to the new version. When I try to update via Xcode, it fails with an error to the device console like that in the Tech Note: “Upgrade's application-identifier entitlement string [....] does not match installed application's application-identifier string [....]; rejecting upgrade.” Trying to update via iTunes seems to fail silently.
I hope that the answer is simply “this error is simply an indication that Xcode has chosen the wrong provisioning profile,” verified as in https://developer.apple.com/library/ios/technotes/tn2318/_index.html#//apple_ref/doc/uid/DTS40013777-CH1-TNTAG65. But I last submitted my app many Xcode versions ago, and finding the right one may be a challenge.
Note the phrasing “Xcode has chosen the wrong provisioning profile”; to make sure that it chose the profile you thought you chose, click on the arrow next to the chosen profile’s truncated name in the archive verification dialog. To double-check this, submit to the App Store with a known error (I inadvertently used a missing icon), so that you see whether the warning appears.
I work for a large, spread out (all over the country) company.
We have a paid iOS Dev Center account and I've been using it to develop iOS apps on phones for months now.
I've now returned to an iOS project after some weeks and it appears that while I was away the existing Development Certificate (the one you use to test and debug on phones, not the Distribution Certificate for the App Store) expired, and someone renewed it.
And now when I download that certificate, it doesn't match the private/public key pair on my system. My guess is that whoever did it generated a new key pair (whether or not they needed to do this I don't know).
So now I guess I need to hunt down the person who did this (it's in the name of the person who signed up for the account but that's not necessarily who did it) so I can get them to export their key pair.
Or I could revoke the certificate and make a new one.
If I do that, will it screw up anyone who's working with the (now revoked) certificate/key pair?
Anybody else who is developing with the new profile should also have the newly created new keys. so you don't necessarily have to hunt down the original person who revoked the old cert.
But if even that is problem then i suggest you revoke and send out the new .p12 to everybody who might need it. And as long as it does not affect the old apps (which it wont) you should be ok.
But on a sidenote your company needs a system to be able to do this efficiently.
I'm pretty sure - if you revoke his certificate, it will simply not be valid and clients will receive errors about unsigned / revoked signing on the app.