January 06, 2015
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.
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?
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!
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.
```bash 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.
```bash 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: ```bash Validity Not Before: Jan 5 05:21:03 2009 GMT Not After : Jan 5 05:21:03 2029 GMT ```
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.