Update Strategies for Changing Certificates

As mentioned in my previous post, switching signatures by applying a second signature is a fact of life for updating AIR applications. If you’re creating such an update to your application each time you get a new certificate, then you’ve solved half of the problem. The other half is to make sure you’ve implemented a matching update strategy in your application.

Unlike the signing half, there’s no requirement that each installed application be updated on a regular basis. This would be impossible to enforce, anyway: If a user takes their machine offline for two years, there’s little to be done. To successfully install updates over time, however, you do need to insure that the sequence of updates installed on any given machine includes one update for each certificate transition.

For example, suppose you’ve run through three certificates: C1, C2, and C3. You’ve got a user who has an older copy of your application signed with C1. To update them to the latest version signed with C3, you need to install two updates on their machine:

  1. An update making the transition from C1 to C2
  2. An update making the transition from C2 to C3

It’d be more convenient to create an update straight from C1 to C3 but, in a typical case, C1 will be long expired before you obtain C3 and therefore not useable for this purpose.

Since you can’t assume the jump from whatever version the user has to the latest version is possible, your update mechanism must provide a method of sequencing updates. That can be as simple as changing the URL used to fetch updates each time you change certificates.

This does not mean you need to have users apply all updates to your application, one by one. For example, suppose you issued three updates to your application after acquiring C2 but while C1 was still useable for applying the second signature: Then you can sign each update twice and any user with a version signed by C1 can jump straight to the latest version signed by C2. Again, what they can’t do is jump to any later version that doesn’t have the second C1 signature.

In conjunction with regular updates, an appropriate update strategy will keep application updates a seamless experience for your users.

4 Responses to Update Strategies for Changing Certificates

  1. Someone says:

    If a user has a C1-signed app installed and doesn’t go online for 2 years, what happens if the C2 cert has expired? Would the user be stuck on C1 since the C1->C2 update won’t apply, and a direct C1->C3 update won’t be possible to generate since C1 has been expired for more than 180 days when C3 is purchased?How does sequencing updates help, really, if C2 is already expired?[AIR signatures are timestamped by default, so the signature remains valid long after the certificate itself has expired. Users will be able to install the C1->C2 upgrade for 10+ years. —Oliver]

  2. Someone says:

    So does that mean that by simply setting back the system clock on my development machine, I can keep using an expired certificate for 10 years, without actually having to renew anything?[No. A signature applied on a machine with its clock set back will not be valid when verified on a machine with a correct clock. —Oliver.]

  3. Someone says:

    That seems to contradict your first comment.What I meant was, if I set back the clock so C1 (or C2) is “valid”, and sign an .air app which I then upload to a web server, would other clients (with correct clock) allow installation (since the .air timestamp is within the expired certificate’s validity timeframe).In other words, how could a user or the air installer determine the difference between a C1->C2 .air that was generated when the C2 cert was valid, and a fake C1->C2 .air that was generated by setting the development machine’s clock back?(Isn’t the air signature generated locally on the development machine?)[The signature is generated locally, but the trusted timestamp is not; it comes from a secure time server. So even if you set your clock back, the timestamp will indicate the true time of signing. If you don’t use a trusted timestamp, then the current time—not signing time—is compared to the certificate’s expiration date and, again, it will be rejected during validation. —Oliver]

  4. Tom Esposito says:

    Oliver,Thanks for the time you spend to outline these important topics to the development community. I’ve got a release coming up on 1/31. My cert expires on 3/4 and I’d like to use this next release as a C1>C2 transition.You mentioned that I could simply sign the air file with both certs. Do you know where I can find more information on that? I’ve been looking and haven’t come across it.Thanks,Tom E[See the documentation on Changing Certificates. —Oliver]