Once someone has installed the app update signed with the new certificate + the migration certificate, any AIR package signed by the new certificate alone will update the existing installation.
Users who did not install an update signed with the migration signature will have to install such an update first (or use the uninstall/reinstall method). The update with migration signature will remain valid indefinitely unless you disabled the timestamp feature when you applied either signature.
OK, that's clear enough, but it still means the user must have a mandatory update to the application to continue with application updates over the remaining certificate lifetime + grace period, which would almost always be at maximum 18 months, and at minimum, well... a day.
It means that developers who sign their apps close to certificate expiration time only have just over 6 months to produce another update. After that their users will be stuck uninstalling and re-installing an update, which is a lousy option. Or, perhaps as you imply, another option is that the user could install some "intermediate" app whose sole function is to carry the certificate forward, but that implies foresight by the developer to produce such an app before grace period expiration.
I just think we need better options than that. If we had the option to chain the app back to the original certificate that would be best.
Thanks for holding this discussion.
I need your help with regards to signing, certificates renewal and publisher id.
Our team is working on a serious AIR app out there, having a considerable install base. We've now renewed our certificate for the second time, but this time the compiler would generate a different publisher ID. How could that possibly happen, anyone any idea?
Please note, that we've already done that before, we're completely aware that publisher id is generated based on details in the certificate. We also had to renew the previous certificate a couple of times, because different details was causing a different publisher ID. It is totally confirmed that all the details in the current certificate are exactly the same, all of them. But still, the publisher ID is different and that is a nightmare. I'll can share other more complicated explorations further on in the discussion, but this is the first question that needs to be answered.
I can't tell from here why the pub ID would be different. One possibility is that the CA changed the certificate used to sign your certificate.
However, because of issues like these, as of version 1.5.3 (released in Dec '09), AIR no longer bases the publisher ID on the certificate. For situations like yours where you have an existing app, you set the original publisher ID in the application descriptor, sign the updates with a migration signature, and updates will work properly. (New apps should not define a pub ID at all.)
The down side to this is that users who don't update for a long time might have to update to an intermediate version before updating to the latest version. This would happen, for example, if a user had version A installed, but the latest version C, was produced more than 6 months after the cert used to sign A expired. The user would have to first install version B and then C (or do an uninstall/reinstall). You could anticipate this problem with custom update logic, but that does take some forethought.
Thanks Joe, really appreciate your answer and I'd kindly ask you follow this conversation with me.
We're already in the process of checking with Thawte if our certificate has been signed with a different certificate.
We also have tried the 1.5.3 migration approach as suggested: "you set the original publisher ID in the application descriptor, sign the updates with a migration signature, and updates will work properly". Unfortunately it doesn't work. Followed that exactly as described in the Certificate Renewals section of the 1.5.3 Release Notes document http://www.adobe.com/support/documentation/en/air/1_5_3/releasenotes_developers.html
Previous certificate has expired on Jan 18, 2010.
Compiling the build with the migration signature goes well.
Unfortunately, when you launch (double click) the .air file, the AIR runtime attempts a brand new installation, instead of updating the existing one (that is signed with the old certificate).
First, please file a bug against AIR at http://www.adobe.com/go/wish
Second, to rule out some obvious errors:
A. You have set the namespace to reflect AIR 1.5.3 in the application descriptor.
B. When you signed the update you did:
- Created the AIR package using the NEW certificate
- Used the ADT -migration command with the OLD certificate
C. The existing installation you are testing has the same publisher ID as specified in the new application descriptor.
D. Can you post the part of your app descriptor where you specify the publisher ID (or PM me)
E. You used the ADT program that came with the 1.5.3 SDK (not an earlier version)
F. The application IDs of the update and the installed version are the same.
We've rulled out possible errors. Actually the test was repeated from the beginning. All your checkpoints are passed.
However, there is some new information that would hopefully help. When the new .air file is built, with the migration signature and everything, it actually doesn't get detected as a brand new application, but it fails to unpack:
Starting app install of file:///Users/triphon/work/triphon_pdc.gugga.com_1666/xxx/head/xxx/air/build/xxxMigrated. air
UI SWF load is complete
Unpackaging to /private/var/folders/DE/DEMJRl6mHJK+f9uulQA75k+++TM/TemporaryItems/FlashTmp0
unpackaging is complete
application is bound to side-by-side version 1.0
application is bound to this version of the runtime
app id xxxxxxxx
pub id xxxxxxxx
failed while unpackaging: [ErrorEvent type="error" bubbles=false cancelable=false eventPhase=2 text="Error #3003" errorID=3003]
starting cleanup of temporary files
application installer exiting
Its totally amazing that the exact same simulation works great, in case we use two active certificates. But with the old build (AIR 1.5.0 namespace), it would get that error.
Any thoughts would be really appreciated.
I apologize for the delay.
Update is always built with the 1.5.3 namespace, it doesn't compile with 1.5.0.
Apparently, the unpacking error that we get is only present on a few computers, for no obvious reason. On most machines it works fine, as well as the migration signature works exactly as expected. That works for us and we are considering the problem resolved.
Thanks very much for your time, it is appreciated!