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.
- Download the .air file
- Change extension to .zip
- Extract or browse the contents of the .zip file
- Open META-INF/signatures.xml
- Look for a
SignatureTimeStampelement. 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.
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.
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
Not After date is waaay in the future, then relax.
Not After date is coming soon, start thinking about how to handle migrating your app to a new certificate.
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.
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.