Verifying that Your Code-Signing Output Files Are Working as Expected on macOS or OS X–Based Target Systems

InstallAnywhere 2018

Regardless of which method you use to prepare your code-signed installers, at various points in the process, it is important to verify whether the target file has been properly code signed before proceeding with the next step of the process.

It is also crucial to test the final output on a clean machine.

If you encounter issues while testing your output files, you can verify that the trust relationship between the helper tool and the authentication wrapper are intact.

Verifying that the Helper Tool, the Authentication Wrapper, and the Installer Have Been Successfully Signed

Regardless of which method you use to prepare your code-signed installers, at various points in the process, it is important to verify whether the target file has been properly code signed before proceeding with the next step of the process.

To verify that the helper tool, the authenticated wrapper, or the installer was signed properly, use the following commands in Terminal:

Testing Your Installer

Before you release your product, it is important to test the final output on a clean machine—one that does not have your Developer ID Application certificate available in the login or system keychains in the Keychain Access utility. Ensure that you are able to successfully install your product when you are logged on to the test machine as a standard user who is not a root user or an administrative user.

Verifying that the Trust Relationship Between the Helper Tool and the Authentication Wrapper Are Intact

In some cases, it is possible that the trust relationship between the helper tool and the authentication wrapper may be broken. Such cases are difficult to identify and debug. One easy way might be to first print out the code-signing requirements of both the helper tool and the authentication wrapper, and compare them. To do so, use the following command:

$> codesign -d -r- <path-to-app>

where <path-to-app> is the path to your helper tool or your authentication wrapper

Run this for both the helper and the authentication wrapper. This produces output on Terminal. Compare the helper tool output with the authentication wrapper output, and look for any mismatches. The identifier portion can differ, but the other portions should match.

The following output samples demonstrate an example of a working relationship.

Helper Tool output:

iadevs-Mac-mini:Build iadev$ codesign -d -r- com.flexera.ia.helper

designated => anchor apple generic and

identifier "com.flexera.ia.helper" and

(certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or

certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and

certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and

certificate leaf[subject.OU] = XXXXXXXXXX)

Authentication wrapper output:

iadevs-Mac-mini:NoVM iadev$ codesign -d -r- install.app

designated => identifier "com.flexera.authenticator" and

anchor apple generic and

certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and

certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */

and certificate leaf[subject.OU] = XXXXXXXXXX

You can also optionally use the following command to obtain additional debugging information:

$> otool -X -s __TEXT __info_plist com.flexera.ia.helper | xxd -r

This assumes that the helper tool (com.flexera.ia.helper) is present in the current directory, and that it can be used to verify that the info.plist file that is injected into the helper tool was customized properly.

See Also

Requirements for Code-Signing Support for macOS or OS X–Based Installers

Troubleshooting Tips for Code-Signing and Authentication Support for macOS or OS X–Based Target Systems

Open topic with navigation