Adobe AIR requires that AIR files, which are used to distribute applications, be digitally signed. This doesn’t just protect your application in transit: The certificate used for signing also establishes the identity of your application. Change certificates and you’ve created a different application.
Application identity is critical when using the Updater API, among other features. If you call the Updater API with an AIR file that wasn’t signed with the same certificate as the caller, Adobe AIR will refuse to install the update. (Users will see an error message about a mis-configuration directing them back to you, the application’s publisher.) This helps prevent anyone from hijacking your application update mechanism–but it also means you need to choose and stick with a single certificate for this application.
Users installing directly from the AIR file will be given the option of installing what appears to be a new application–not an update to the old one. If you have to switch certificates, you’ll probably want to ask users to uninstall the old application.
What happens when your certificate expires? Updates will still work, as renewed certificates are allowed. It’s the identity of the signer as found in the certificate, not the entire certificate, that’s used to perform this validation. The identity in the certificate doesn’t change across a renewal.
Lately I’ve been asked several times about how to get an installed version of Adobe AIR updated. After all, applications can update themselves via the Updater API. But what if the new version of the application requires a new version of Adobe AIR itself?
The answer is that AIR will update itself–and has been updating itself since the beta 2 release. If you’ve got Adobe AIR Beta 2 installed and you encounter an application that is bound to the beta 3 release, installing that application will trigger an update of AIR itself to beta 3. This happens in all installation scenarios: via the Updater API, double-clicking on an .air file, and through Badge Install. 
The update happens fairly transparently; there isn’t much in the way of additional UI that’s shown. More time is spent on the progress bar, of course–the update has to be downloaded and decompressed. Users might notice that there’s an additional check box in the UI indicating that the update is going to be applied. Finally, in some cases, an updated EULA may be shown and require agreement.
What happens to all those other beta 2-based applications on your machine? They’ll keep running until beta 2 expires, as beta 3 installs side-by-side.
You can–and should–use the same mechanism to update your applications to the final 1.0 release when it ships. 1.0 installs side-by-side with the beta releases, so your beta applications can continue to run–again, until the betas expire.
 OK, with one exception: Using the Updater API to update an application from beta 2 to a later release doesn’t work on Vista. Sorry about that. It’s fixed in beta 3.