January 6, 2015

Adobe AIR desktop apps, expiring signing certificates, and the developer

Is the app timestamped?

Here is the important bit about timestamping from Adobe’s ‘Digitally signing an AIR file’ documentation

When you sign an AIR file, the packaging tool queries the server of a timestamp authority to obtain an independently verifiable date and time of signing. The time stamp obtained is embedded in the AIR file. As long as the signing certificate is valid at the time of signing, the AIR file can be installed, even after the certificate has expired. On the other hand, if no time stamp is obtained, the AIR file ceases to be installable when the certificate expires or is revoked.

  1. Download the .air file
  2. Change extension to .zip
  3. Extract or browse the contents of the .zip file
  4. Open META-INF/signatures.xml
  5. Look for a SignatureTimeStamp element. If it is there, the AIR app is timestamped

The app I’m working with is timestamped, so it can be installed indefinitely. But what about updates?

Expired certificates and app updates

Here’s another important bit from Adobe’s documentation

As of AIR 1.5.3, a certificate that has expired within the last 180 days can still be used to apply a migration signature to an application update. To take advantage of this grace period, and the update application descriptor must specify 1.5.3 in the namespace attribute. After the grace period, the certificate can no longer be used. Users updating to a new version of your application will have to uninstall their existing version. Note that there is no grace period in AIR versions before 1.5.3.

If an app uses AIR 1.5.3 or newer, the developer has 180 days past certificate expiry date to migrate to a new certificate. Time to find expiry the date!

Checking when a signing certificate expires

Assuming you have access to the .p12 version of the certificate and the password, you can follow these instructions (based on these from BSD Support). You can use the CLI application openssl (comes with Linux and OS X, msysgit for Windows includes it) to complete these steps.

  1. Convert the .p12 to a .pem file

    openssl pkcs12 -in certificate.p12 -out tempcrt.pem

    You will also be asked to provide the .p12’s password, and a new password to secure the resulting .pem file.

  2. Check the expiry date of the .pem file

    openssl x509 -in tempcrt.pem -text

    This will output a few screens of information in your terminal, including valid dates for the certificate. Here’s what you are looking for:

    Validity
  Not Before: Jan  5 05:21:03 2009 GMT
  Not After : Jan  5 05:21:03 2029 GMT

How to react as the AIR app’s developer

Put the dates in your calendar

If the Not After date is waaay in the future, then relax.

If the Not After date is coming soon, start thinking about how to handle migrating your app to a new certificate.

If the Not After date has passed less than 180 days ago and your app uses AIR 1.5.3 or newer, it is time to migrate to a new certificate. If the app uses an older version of AIR, it is too late to migrate to a new certificate to allow for smooth updates.

If the Not After date is more than 180 days ago, migrating the application to a new certificate is not an option. Users will have to uninstall and re-install your application instead of updating it.