Posts in Category "code signing"

Disabling AIR Certificate Revocation Checks During Silent Install

Here’s a quick tip that doesn’t seem to be covered in the administrator’s guide for AIR, although it likely should be: You can control how revocation checks are performed during silent installs via the -revocationCheck flag.

When digital signatures are validated, one step in the process involves checking to see if the certificate used to sign has been revoked. This is how certification authorities defend against stolen certificates: they revoke stolen certificates by publishing them in a revocation list; software that validates signatures then checks those lists.

Revocation lists are published to web servers at URLs embedded in the certificates themselves. In order to check the lists, they need to be downloaded. This gives rise to a number of potential questions, like what to do when you are offline and can’t download the latest version. One needs to make a policy decision to answer such questions.

The -revocationCheck flag accepts four values, one for each supported policy:

  • never Don’t check the list, period. No network requests will be issued. (More on this below.)
  • bestEffort Look for a revocation list, but if something goes wrong other than the certificate being revoked, proceed on the assumption that everything is ok.
  • requiredIfInfoAvailable Assuming you can fetch the revocation list, then fail if any later errors occur. But if you can’t download the list at all, proceed as for bestEffort.
  • alwaysRequired If the revocation list can’t be checked without error, don’t proceed.

AIR defaults to “bestEffort”. That’s typically a reasonable choice, and it has the advantage of working both online and offline. But it does mean that for most installations, the AIR installer will at least attempt to issue a network request to download the list. (Lists are also cached, so you won’t always see the request, however.)

Now, there’s one particular case where “never” is a handy setting: Silent installation behind an HTTP proxy that requires authentication. In this situation, so long as AIR issues a network request, the OS will typically pop up a proxy authentication dialog, which of course halts the installation flow and requires manual intervention. To work around it, simply add “-revocationCheck never” to your command line arguments.

AIR 2.6 Extended Migration Signature Grace Periods

Returning to the ever-popular subject of the AIR desktop signing mechanism, I want to point out that the grace period for applying a migration signature with your old certificate has been extended from six months (AIR 2.5 and earlier) to one year (AIR 2.6 and beyond).

Those familiar with the details will recall that updating to a new certificate for a desktop AIR application goes something like this:

  1. Sign the new version of the app with your new certificate.
  2. Sign the new version of the app a second time with your old certificate.

The second signature is referred to as the migration signature.

The new certificate, not surprisingly, must be valid when used to sign. For the old certificate, however, we allow a grace period after the certificate expires. This avoids the need to have both certificates valid at the same time, which can be difficult to arrange. This period was initially six months, but this proved a bit too short in some situations. As of AIR 2.6, the grace period is now one year.

For more background in this area, you might want to read:

Certificate Support in AIR for Linux

In an earlier post I explained how to use TLS client authentication for AIR applications on Windows and Mac OS. Commenter Arlen asked how to do the same on Linux; unfortunately, TLS client authentication is not supported in AIR for Linux.

The first problem is that, unlike Windows and Mac OS, Linux doesn’t have a standardized, easily accessible certificate store available. Instead, AIR bundles its own certificate stores. (See this Adobe knowledge base article for information about managing those certificate stores.) Other Linux applications typically do the same. Even if client authentication was supported, it would have be configured separately for AIR applications versus other applications, thus making it much less useful than on Windows or Mac OS.

The second problem is that Linux doesn’t have a standardized, easily accessible HTTP stack that supports TLS client authentication—instead, applications have to bundle their own implementation. That, of course, doesn’t make it impossible for AIR to add this support, but it means it requires a non-trivial engineering investment.

To date, these two issues have kept us from adding TLS client authentication support on Linux. If you’d like to see it added, I encourage you to vote for it on the Adobe AIR Ideas site.

GlobalSign Individual Developer Certificates

I’ve posted several times in the past on the importance of using a trusted certificate, even though obtaining a trusted certificate takes both time and money. While some certification authorities continue to issue code signing certificates only to businesses, I was pleased to learn recently that GlobalSign has joined the ranks of those make certificates available to individuals as well. See the GlobalSign Code Signing page for further information.

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.

Upcoming Certificate Renewal Changes in Adobe AIR

AIR currently secures application updates published with renewed certificates by comparing the publisher ID computed from the old and new certificates. If the publisher IDs are identical the update is allowed; otherwise, it’s not.

Recently we’ve been made aware that the publisher ID computation is flawed in ways that make it quite likely that renewed certificates will not have identical publisher IDs. These range from the trivial to the unresolvable:

  • In one case, an original certificate contained a typo in the publisher’s identity. This was corrected in the renewal. However, the publisher ID computation requires that the publisher’s identity matches exactly.
  • In another case, similar, key information changed–but in one of the intermediate certificates in the certificate chain. The change was legitimate, but again fell outside the scope of changes that the publisher ID computation allows.
  • In perhaps the most serious issue, the publisher ID algorithm requires that the root certificate in the certificate chain be identical across renewals. Root certificates are typically valid for 20 years or more, so this was not anticipated as a serious limitation. However, many root certificates will be retired in the next few years in favor of certificates with longer key lengths–long before they expire.

If you’ve run into this situation, you should use the migration signature feature, which was first added in AIR 1.1. It was originally designed to allow secured updates across unrelated certificates (i.e., not renewals). As a general purpose mechanism, however, it also works just as well with renewals, whether or not they run into this issue.

There are, however, two drawbacks to the migration signature mechanism:

  1. You have to use the mechanism before your old certificate expires. Certificate renewals are often issued only after the previous certificate has expired.
  2. When you migrate between certificates your publisher ID changes. Among other things, this causes the application to lose access to any data stored in the EncryptedLocalStore.

This is an unfortunate turn of events for a feature that was designed to make things easier, and we apologize for the trouble all of this has caused. To address these issues, we will be making two significant changes in an otherwise minor release of AIR. This release is currently scheduled for December. The changes are:

  1. Applications will use a specified, not computed, publisher ID. This will allow them to change certificates without losing access to existing data.
  2. For purposes of changing certificates, certificates will be accepted as valid for six months after they expire. This allows plenty of time to renew and update the application.

Further details will be made available in conjunction with the upcoming release.

Why AIR fetches a Thawte CRL no matter who signed your app

I was recently asked why AIR fetches a Thawte CRL (from http://tss-geotrust-crl.thawte.com/ThawteTimestampingCA.crl) every time an application is installed–even if the application was signed with a certificate from another CA. It turns out there is a good reason for this, and the clue is in the URL itself.

By default, all AIR application signatures are timestamped. Timestamps are created by a timestamp server, and are themselves signatures. When AIR validates the timestamp signature, it downloads the CRL associated with the timestamp signing certificate–just like it would when validating any other signature. And the Thawte timestamp server uses a certificate that–no surprise here–has a CRL hosted by Thawte.

This default is easy to override using the “-tsa” option to the AIR file packaging tool, adt. A value of “-tsa none” turns off timestamps entirely. To specify an alternate timestamp server, specify the URL of that server after the -tsa flag.

For more on AIR code signing, including why timestamping is used, take a look at Code Signing in Adobe AIR.

Revised AIR 1.5.2 Application Install Experience

The Adobe AIR 1.5.2 release is now available. There are relatively few changes in it, given that it’s a minor release, but I’ll nonetheless be posting a few entries about the more interesting changes.

Perhaps most interesting of all is that we’ve revised the much-loved unrestricted system access warning that’s displayed during application install. I think you’ll be pleased with the new design:

AIR1.5.2RevisedPublisherPanel.png

Please note that this change applies only to applications signed with certificates that are trusted on the targeted machine. I hope you’ll find some comfort in knowing that we do, indeed, listen to–and appreciate–your feedback.

ChosenSecurity Individual Developer Certificates

Most certification authorities will issue certificates only to businesses. This can be a drag for individuals publishing applications on their own. If you’re in that camp, you may want to take a look at ChosenSecurity’s AIR code signing certificates, which are available to individuals.

No, I’m not receiving anything from ChosenSecurity for posting this.

GlobalSign Code Signing Certificate Discount

GlobalSign is currently running a discount on Adobe AIR code signing certificates, selling one-year certificates for $99.

If your applications are publicly available, you should be using a CA-issued certificate, such as one from GlobalSign, VeriSign, or Thawte. This price is a discount of $130, making this a good time to make the switch. See Code Signing in Adobe AIR for more on why this matters, and Switching Certificates for information on how to transition from your current certificate to a new one.

For those who are wondering, no, I’m not receiving anything from GlobalSign for posting this.