- Core Requirements
- Deployment Planning Strategy
- Initial Signing Process
- Testing Process
- What's Next?
Initial Signing Process
The third requirement was part of packaging (compiling) an AIR application. All AIR apps must be digitally signed before they can be created and deployed. There are two ways to sign an AIR application: by using a temporary certificate (PK12) file, or by using an official verified certificate.
Flash Builder provides developers with an easy way to generate a simple PK12 for testing purposes. The challenge with a temporary certificate is that it doesn't verify the publisher, which means that the user will receive a warning on installation, as shown in Figure 2. To verify the publisher, a digital certificate must be used that has been issued by a Certificate Authority (CA).
Figure 2 Unverified certificate warning received during installation.
Adobe has an official certificate for signing, but the process required to use it is intensive and takes a fair bit of time. This process keeps the certificate safe, so that it doesn't accidentally (or even maliciously) become available to the public. Knowing that this process takes time, especially in larger companies, required that we start the certificate acquisition process as soon as possible.
The official certificate signing process is only required at the end of the release cycle, right before the product is posted online. For development and testing purposes, we could use the simple temporary PK12 file. However, the same PK12 file had to be used by all the developers, in order to prevent installer errors. For example, if Aaron signed a build with a PK12 he generated on his machine, and then James signed a build with a PK12 he created, anyone updating the test version could get an error, depending on who signed the previous build first. If Doug installed the version from Aaron and then tried to install the version from James, the AIR installer would throw an error. AIR only allows you to update an installed application as long as the digital signatures match. Because James and Aaron created their own certificates, they wouldn't match.
To prevent this problem, we created a single temporary certificate and shared it among the team by using Dropbox. This technique allowed everyone to create a test build using the same certificate, thereby preventing digital signature mismatches.