Digital signatures show where programs come from and verify that they haven't been altered. You should digitally sign your customized browser packages and any custom programs to ensure that users don't receive warnings when installing the custom browser. Users may be prevented from installing ActiveX controls and Java packages that aren't signed. You must specify information about your digital certificate when using the Internet Explorer Customization wizard.
If you plan to distribute custom packages for 32-bit versions of the browser over the Internet, you should have the IEAK sign the custom cabinet (.cab) files that it creates. If you plan to distribute your custom packages over an intranet, you should sign the custom files, unless you preconfigure the Local Intranet zone with a Low security setting. The default security setting will not allow users to download programs or code that isn't signed. For more information about security zones, see Internet Explorer 5 Security.
Signing the .cab files and custom programs requires two steps: obtaining a digital certificate and signing the code. You do not need to sign files for 16-bit or UNIX versions of the browser.
You can now use the IEAK to sign your custom packages. You will need to obtain a digital certificate to sign your files with. You will designate the location of the certificate when you run the Internet Explorer Customization wizard, and it will sign the files when the package is created.
These custom files will be signed:
Notes
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:
Digital certificates are a part of Authenticode technology, which identifies where programs come from and verifies that programs haven't 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/.
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.
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.
If you're 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 end users receive warnings when they try to view potentially unsafe content. You can also prevent users from downloading unsigned ActiveX controls and Java packages.
The code-signing process is simple and quick. It isn't 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 don't match, either the code was modified or the public and private keys aren't a matched pair. In either case, the code becomes suspect and the user is warned.