AIR 2.6 Extended Migration Signature Grace Periods

Returning to the ever-popular subject of the AIR desktop signing mechanism, I want to point out that the grace period for applying a migration signature with your old certificate has been extended from six months (AIR 2.5 and earlier) to one year (AIR 2.6 and beyond).

Those familiar with the details will recall that updating to a new certificate for a desktop AIR application goes something like this:

  1. Sign the new version of the app with your new certificate.
  2. Sign the new version of the app a second time with your old certificate.

The second signature is referred to as the migration signature.

The new certificate, not surprisingly, must be valid when used to sign. For the old certificate, however, we allow a grace period after the certificate expires. This avoids the need to have both certificates valid at the same time, which can be difficult to arrange. This period was initially six months, but this proved a bit too short in some situations. As of AIR 2.6, the grace period is now one year.

For more background in this area, you might want to read:

5 Responses to AIR 2.6 Extended Migration Signature Grace Periods

  1. Rich says:


    I use Flash Professional to create my AIR apps. How do I sign an app with two certificates in Flash? Do you know of any tutorials that guide you through the process?

    Kind Regards

    • Oliver Goldman says:

      As far as I know, Flash Pro doesn’t offer UI for this; you’ll need to use the command-line tools available in the AIR SDK and Flex SDK.

  2. JS says:

    Hi Oliver,

    How do you migrate certificates when you do not use an “.air” file (ie: -target bundle)?
    All the code signing examples assume you have an air file.

    • Oliver Goldman says:

      If you are using the “-target bundle” option, then migration signatures simply aren’t used. Use of the bundle option implies that you are selecting and using your own installation technology; that installation technology is not related to the signature mechanism that’s used by .air files. Hence the implicit assumption in the examples that an .air file is relevant.

      If you are using the “native” installers created directly by AIR with “-target native”, then migration signatures are used just as for .air files. In this scenario, the native installers can be though of as wrapping an .air file in a native installer package, and the AIR installation technology is still invoked during the installation.

  3. JS says:

    Thanks Oliver, that’s great information.
    My main concern about the migration was because I still need to provide a cert when packaging, even when using the captive runtime option, so I wasn’t sure if I can change the cert when it expires and whether I can instead use a self-signed one.