Skip navigation
Currently Being Moderated

How long can the same publisher ID be used to update an app

Jan 4, 2010 7:38 PM

I recently signed an update with ADL 1.5.3 using the original publisherID in the app descriptor and 1.5.3 in the namespace. It currently works fine, updating the original app as expected.


The original app was signed using ADL 1.5.1 (or 1.5.2... can't remember). Now lets say 6 months (the grace period) elapses and the client wants to update the app again. I'll need to sign the app WITHOUT a migration signature since the grace period for the original certificate has passed. Will users of the original app be able to update without un-installing if publisherID is specified in the namespace?


I think the answer is no, since that would mean that anyone could spoof anyone's app just by knowing the publisherID. However it's bad user experience to require the un/re-install, and also a pain to develop around (user settings migration from ELS, etc). Can't ADL have some kind of chainmigrate command, where in order to migrate a signature, one could line up certs back to the one that produced the original publisherID?

  • Currently Being Moderated
    Jan 5, 2010 12:34 PM   in reply to tedalde2

    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.

    Mark as:
  • Currently Being Moderated
    Jan 8, 2010 10:54 AM   in reply to tedalde2

    We did a research on how developers renew their certificates and come to the current implementation as a good compromise.

    Mark as:
  • Currently Being Moderated
    Feb 24, 2010 11:11 AM   in reply to tzeng

    HI Guys,


    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.


    Please reply.


    Kind Regards

    Stefan Yotov

    Mark as:
  • Currently Being Moderated
    Feb 24, 2010 12:53 PM   in reply to stefanyotov



    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.

    Mark as:
  • Currently Being Moderated
    Feb 25, 2010 12:07 PM   in reply to Joe ... Ward

    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 evelopers.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).


    Please advise!


    Thank you


    Mark as:
  • Currently Being Moderated
    Feb 25, 2010 1:41 PM   in reply to stefanyotov

    First, please file a bug against AIR at


    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:

    1. Created the AIR package using the NEW certificate
    2. 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.

    Mark as:
  • Currently Being Moderated
    Mar 1, 2010 5:05 AM   in reply to Joe ... Ward

    Thanks Joe,


    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/ai r/build/xxxMigrated.air

    UI SWF load is complete

    UI initialized

    Unpackaging to /private/var/folders/DE/DEMJRl6mHJK+f9uulQA75k+++TM/TemporaryItems/Fl ashTmp0

    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.


    Thanks again


    Mark as:
  • Currently Being Moderated
    Mar 1, 2010 10:22 AM   in reply to stefanyotov

    When you say, "But with the old build (AIR 1.5.0 namespace), it would get that error..." Do you mean the update was built using the 1.5.0 namespace (which wouldn't be expected to work), or that the old, installed version was built using the AIR 1.5.0 namespace?

    Mark as:
  • Currently Being Moderated
    Mar 1, 2010 5:34 PM   in reply to stefanyotov

    Hi Stefan,


    We would like to help you to figure out what the problem could be. I have sent you an email to ask for more info.

    Could you take a look at my email?





    Mark as:
  • Currently Being Moderated
    Mar 15, 2010 7:49 AM   in reply to Joe ... Ward

    Hi Joe,


    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!



    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points