Export (0) Print
Expand All

Signing Your Programs

You can use the IEAK to digitally sign your custom packages. Digital signatures show where programs come from and verify that they have not been altered. Signing your customized browser packages and any custom programs ensures that users do not receive warnings when installing the custom browser.

First, however, you need to obtain a digital certificate with which to sign your files. You designate the location of the certificate when you run the Internet Explorer 6 Customization Wizard, and it signs the files when the package is created. For information on obtaining a digital certificate, see the following section, "How do I obtain digital certificates?"

If you plan to distribute custom packages over the Internet, have the IEAK sign the custom cabinet (.cab) files that it creates. If you plan to distribute your custom packages over an intranet, sign the custom files or preconfigure the Local intranet zone with a Low security setting. The default security setting does not allow users to download unsigned programs or code. For more information about security zones, see Internet Explorer Security.

These custom files are signed:


Function of this file


Branding information for Windows Update Setup


Windows Desktop Update


Identifies which Microsoft Internet components are installed as part of Windows Update Setup


Windows Update Setup


Custom components installed after the system restarts. Each component is packaged into a separate, numbered .cab file.

For a flowchart of how the Internet Explorer 6 Customization Wizard creates these files, see How the IEAK Generates Custom Packages.

Note Note 

  • Users may be prevented from installing ActiveX controls and Java packages that are not signed.

  • You also need to sign any custom programs, in either .exe or .cab format, that you include in your browser package.

  • If you expect your organization to use Install on Demand over the Internet, you must sign the .cab files and specify in the security settings that the server hosting the .cab files is a trusted server, or for an intranet site only, set the security level to Low. For more information about this feature, see Managing Install on Demand.

To specify your network servers as trusted

If your intranet security level is set to Medium or higher, you must then specify your network servers as trusted servers. To do this, carry out the following steps:

  1. On the Security Settings page in the wizard, click Import the current security zone settings, and then click Modify Settings.

  2. Select the Local intranet zone, and then click Sites.

  3. Clear the Include all network paths (UNC) check box, and then click OK.

  4. Select the Trusted sites zone, click Sites, type the path for the download server, and then click Add.

  5. Repeat the previous step for every download server that you want to specify as trusted.

Obtaining digital certificates

Digital certificates are a part of Authenticode technology, which identifies where programs come from and verifies that programs have not changed. You can obtain certificates from a certification authority or a privately controlled certificate server. Certificates can be commercial or individual.

For more information about Authenticode and security, see the Microsoft Security Advisor Web site at http://www.microsoft.com/security.

Signing cabinet files or custom programs

After obtaining a certificate, you will need to sign the code. Tools for signing code are available from the Microsoft Site Builder Network Workshop.

You will also need to know the public and private keys, which are a matched set of keys created by the software publisher for encryption and decryption. The keys are generated at the time the certificate is requested from a certification authority (CA). They are generated on your computer, and your private key is never sent to the CA or any other party.

Working with expiring certificates

The expiration of certificates provides an added measure of security. For example, if a university certifies all of its students with digital identifiers (IDs), it can set each ID to expire when the student leaves the university. Code that is signed with an expired certificate is invalid. After the certificate expires, the software publisher needs to resign the code and post new versions of it.

Software publishers can use a time stamp to sign code to prove that the certificate was valid at the time the code was signed. Then the signed code will remain valid even after the certificate expires.

Using Authenticode to control what users see

If you are a corporate administrator, you can preconfigure security zones, preset ratings, and customize certification authorities. You can also set system policies and restrictions to control whether users can modify their security settings. For information about specific settings, see Internet Explorer Security Options.

You can ensure that users receive warnings when they try to view potentially unsafe content. You can also prevent users from downloading unsigned ActiveX controls and Java packages.

Understanding what happens when you sign your code

The code-signing process is simple and quick. It is not necessary to know the technical details of how code-signing works to sign your code.

After developing and testing code, a software publisher signs the code file. The publisher uses a signing program, such as Signcode.exe, to hash the code, producing a "digest" of the file. Through the operating system layer, the program encrypts the digest with the private key and combines the digest with the name of the hash algorithm and CA certificate (containing the publisher name, public key, and so on) into a structure called a signature block. The program then embeds the block back into the code file, and the file is ready to be distributed over the Internet. Note that a .cab file that gets signed also contains a signature block.

When the user downloads the file from the Internet, the downloading application calls a verification function. As a result of that call, the operating system extracts the signature block, determines the CA who validated the certificate, and uses the public key to decrypt the digest. The system then uses the hash algorithm indicated in the signature block to create a second digest. If the code has not been modified since it was signed, the new digest should match the old one. If the two digests do not match, either the code was modified or the public and private keys are not a matched pair. In either case, the code becomes suspect and the user is warned.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
© 2014 Microsoft