
Here are two examples of how to sign and timestamp a file using the Internet Explorer 4.0 options. The first uses the MyKey key container and the second uses a private-key file My.pvk:
SignCode -spc Cert.spc -k MyKey -n "My control" -i http://www.my.com -$ commercial -t http://timestamp.verisign.com/scripts/timstamp.dll MyControl.exe
SignCode -spc Cert.spc -v My.pvk -n "My control" -i http://www.my.com -$ commercial -t http://timestamp.verisign.com/scripts/timstamp.dll MyControl.exe
In both cases a PKCS #7 object, Cert.spc, is embedded into the digest of the file, MyControl.exe. In the first example, the digest is signed with the private key of the MyKey key container, and a timestamp is added. In the second example, the digest is signed with the private-key file My.pvk, and a timestamp is added.
The following example shows how to sign and timestamp a file using a certificate in my store (the default certificate store). The certificate's common name is MyCert, and the program being signed has the friendly name My Control.
SignCode -cn "myCert" -n "My control" -i http://www.my.com -$ commercial -t http://timestamp.verisign.com/scripts/timstamp.dll MyControl.exe
The following example shows how to sign and timestamp a file using a certificate in theCert store. There is assumed to be only one certificate in the certificate store, so it is not necessary to identify the certificate. The certificate store is at the default registry location, HKEY_CURRENT_USER. My control is the friendly name for the program being signed.
SignCode -s "theCert" -n "My control" -i http://www.my.com -$ commercial -t http://timestamp.verisign.com/scripts/timstamp.dll MyControl.exe
A timestamp should always be added when a file is signed. However, if a file was signed without a timestamp, a timestamp can be added to that file. Here is an example of how to add a timestamp to a previously signed file:
For Internet Explorer 3.02 UPD:
SignCode -prog MyControl.exe -nosigning -timeStamper http://timestamp.verisign.com/scripts/timstamp.dll
For Internet Explorer 4.0:
SignCode -t http://timestamp.verisign.com/scripts/timstamp.dll -x MyControl.exe
Notice the -x option is used in conjunction with the -t option to indicate that the file to be timestamped has already been signed. If you try to timestamp a file previously signed by Internet Explorer 3.0 tools, the timestamp may fail with an error saying you must re-sign. If you timestamp a previously signed file using the SignCode tool for Internet Explorer version 3.02 UPD or 4.0, it should successfully add the timestamp. The signing and timestamping concurrent operation should always work, even if the file was previously signed by Internet Explorer 3.0 tools, because if there is an old signature it is replaced.
The -j and jp options are provided for more advanced users of SignCode and Internet Explorer 4.0 only. The user can write a Dynamic Link Library (DLL) with predefined entry points that returns an array of authenticated or unauthenticated attributes for signing files. SignCode will take the following actions using these options:
There are four pre-defined entry points for the DLL:
HRESULT WINAPI InitAttr(
LPWSTR pInitString); // IN: the initialization string
HRESULT WINAPI GetAttr(
PCRYPT_ATTRIBUTES *ppsAuthenticated, // OUT: Authenticated attributes added to signature
PCRYPT_ATTRIBUTES *ppsUnauthenticated); // OUT: Unauthenticated attributes added to signature
HRESULT WINAPI ReleaseAttr(
PCRYPT_ATTRIBUTES psAuthenticated, // OUT: Authenticated attributes to be released
PCRYPT_ATTRIBUTES psUnauthenticated); // OUT: Unauthenticated attributes to be released
HRESULT WINAPI ExitAttr( );
SignCode calls these entry points in the following order:
The ChkTrust program checks the validity of a signed file by:
If the hashes agree, ChkTrust then verifies that the signer's X.509 certificate is traceable back to the root certificate and that the correct root key was used.
If all these steps are successful, it means that the file has not been tampered with, and that the vendor who signed the file was authenticated by the root authority.
Here is the syntax:
ChkTrust [options] signedFile
where the options are:
| For IE 4.0 | For IE 3.02 UPD | Description |
| N/A | -c | Indicates that the signed file is a cabinet file. |
| N/A | -i | Indicates that the signed file is a PE image file. Includes .exe, .dll, and .ocx files. |
| -q | -n | Do not display user interface. |
| -? | N/A | Displays all of the options. |
In the IE 4.0 version, ChkTrust can distinguish file types automatically, so the -c and -i switches used in the IE 3.02 UPD version are obsolete. Here is an example for the IE 3.02 UPD version:
ChkTrust -i MyProgram.exe
A successful response would be:
Result: 0
Here is an example for the IE 4.0 version:
ChkTrust MyProgram.exe
Note that versions of ChkTrust that are older than the one released with Internet Explorer 3.02 UPD cannot validate files signed with this release of Authenticode.
The MakeCTL utility creates a certificate trust list (CTL) and outputs the encoded CTL to a file. MakeCTL is supported in IE 4.0 only.
The input to MakeCTL is an array of certificate stores. MakeCTL will build a CTL which includes the SHA1 hash of all of the certificates in the certificate stores. A certificate store can be one of the following:
The syntax for invoking MakeCTL is:
MakeCTL [-u subjectUsageID] [-s [-r registryLocation]] store1 [-s [-r registryLocation]] store2 ... [-s [-r registryLocation]] storeN output.ctl
where:
The options are as follows:
| -u subjectUsageID | The CTL subject usage identifier. The default identifier is szOID_TRUSTED_CODESIGNING_CA_LIST, which specifies that the CTL consists of root CAs for code signing. |
| -s | Indicates that the certificate store is a system store. |
| -r registryLocation | The registry location of the system certificate store. Meaningful only when s is set. Must be set to either currentUser or localMachine. The default setting is currentUser.
currentUser means that the certificate store is under the registry key HKEY_CURRENT_USER. localMachine means that the certificate store is under the registry key HKEY_LOCAL_MACHINE. |
| -? | Lists command syntax and options. |
An encoded CTL file must be signed before using. CTL files can be signed using the SignCode utility. Once the CTL file is signed, it can be moved to the trust system store by CertMgr. CertMgr can also move the CTL's signer certificate to the root store. If the subject usage identifier of the CTL is szOID_TRUSTED_CODESIGNING_CA_LIST (the default), all the files signed by certificates in the CTL will be trusted by ChkTrust and Authenticode.
The following example generates a CTL that includes all the certificates in a system certificate store named root:
MakeCTL -s root output.ctl
The following example generates a CTL that includes an array of certificates:
MakeCTL one.cer two.cer three.cer output.ctl
The CertMgr utility is a replacement for DumpCert and adds many new capabilities. CertMgr can manage certificates, certificate trust lists (CTLs), and certificate revocation lists (CRLs). The functionality of CertMgr has three parts:
Each functional part of CertMgr has its own syntax and options group. The syntax and options for different functional parts cannot be mixed.
CertMgr works with two kinds of certificate stores, StoreFile and system store. A StoreFile can be one of the following kinds of files:
It is not necessary to specify the type of the StoreFile. CertMgr can determine the StoreFile type and take the appropriate actions.
A system store is located in the user's registry. The user can refer to a system store by providing just its name. It is not necessary to specify the certificate store provider type. Depending on the type of the StoreFile or system store, CertMgr will choose the corresponding store provider type.
The syntax for invoking CertMgr to display certificates, CTLs, and CRLs is as follows:
CertMgr [options] [-s [r registryLocation]] StoreName
StoreName is the name of the certificate store containing the items to display. The store can be a serialized store (StoreFile) or a system store (in the registry). By default, CertMgr will display all the certificates, CTLs, or CRLs in the store, unless otherwise specified in the options.
The options are:
| -v | Verbose mode. Displays detailed information about certificates, CTLs, and CRLs. The default is to display brief information. |
| -c | Only display certificates. |
| -CTL | Only display CTLs. |
| -CRL | Only display CRLs. |
| -e encodingType | Certificate encoding type. |
| -y storeProviderType | Store provider type. |
| -f dwFlags | Store open flag. This is the dwFlags parameter passed to CertOpenStore. The default value is CERT_SYSTEM_STORE_CURRENT_USER. Meaningful only if y is set. For more information see the CryptoAPI 2.0 documentation. |
| -s | Indicates the store is a system store. If this option is not set, the store is a StoreFile. |
| -r registryLocation | Identifies the registry location of the system certificate store. Meaningful only when s is set. Must be set to either currentUser or localMachine. CurrentUser is the default. currentUser means that the certificate store is under the registry key HKEY_CURRENT_USER, localMachine means HKEY_LOCAL_MACHINE. |
| -? | Displays all the options. |
The syntax for invoking CertMgr to add certificates, CTLs, and CRLs is as follows:
CertMgr add [options] [-s [r registryLocation]] SourceStore [-s [r registryLocation]] DestinationStore
SourceStore is the source certificate store that contains the existing certificates, CTLs, and CRLs. DestinationStore is the destination certificate store to which the certificates, CTLs, and CRLs will be added to. The destination store will be saved as a serialized store, unless the 7 option is used, which saves the store as a PKCS#7. Note that the 7 option can not be used when the destination store is a system store.
CertMgr can add either certificates, CTLs, or CRLs. If there is more than one item in one of these categories, the user has three options:
This functionality of CertMgr can be used to copy and move certificates, CTLs, and CRLs. See the examples following the options.
The options are:
| -c | Add certificates. |
| -CTL | Add CTLs. |
| -CRL | Add CRLs. |
| -all | Add all entries. |
| -7 | Save the destination store as a PKCS#7. |
| -e encodingType | Certificate encoding type. |
| -y storeProviderType | Store provider type. |
| -f dwFlags | Store open flag. This is the dwFlags parameter passed to CertOpenStore. The default value is CERT_SYSTEM_STORE_CURRENT_USER. Meaningful only if y is set. For more information see the CryptoAPI 2.0 documentation. |
| -n commonNameString | The common name of the certificate to add. Can be used only with certificates. |
| -s | Indicates the store is a system store. If this option is not set, the store is a StoreFile. |
| -sha1 sha1Hash | The SHA1 hash of the certificate, CTL, or CRL to add. |
| -r registryLocation | Identifies the registry location of the system certificate store. Meaningful only when s is set. Must be set to either currentUser or localMachine. CurrentUser is the default. currentUser means that the certificate store is under the registry key HKEY_CURRENT_USER, localMachine means HKEY_LOCAL_MACHINE. |
| -? | Displays all the options. |
The syntax for invoking CertMgr to delete certificates, CTLs, and CRLs is as follows:
CertMgr del [options] [-s [r registryLocation]] SourceStore [-s [r registryLocation] DestinationStore]
SourceStore is the source certificate store that contains the existing certificates, CTLs, and CRLs. DestinationStore is the destination certificate store which will contain copies of the remaining certificates, CTLs, and CRLs after the specified items have been deleted. If DestinationStore is not specified, SourceStore will also serve as the destination store (it will be modified.) The destination store will be saved as a serialized store, unless 7 option is used, which saves the store as a PKCS#7. Note that the 7 option cannot be used when the destination store is a system store.
CertMgr can delete either certificates, CTLs, or CRLs. If there is more than one item in one of these categories, the user has three options:
The options are:
| -c | Delete certificates. |
| -CTL | Delete CTLs. |
| -CRL | Delete CRLs. |
| -all | Delete all entries. |
| -7 | Save the destination store as a PKCS#7. |
| -n commonNameString | The common name of the certificate to delete. Can be used only with certificates. |
| -sha1 sha1Hash | The SHA1 hash of the certificate, CTL, or CRL to delete. |
| -e encodingType | Certificate encoding type. |
| -y storeProviderType | Store provider type. |
| -f dwFlags | Store open flag. This is the dwFlags parameter passed to CertOpenStore. The default value is CERT_SYSTEM_STORE_CURRENT_USER. Meaningful only if y is set. For more information see the CryptoAPI 2.0 documentation. |
| -s | Indicates the store is a system store. If this option is not set, the store is a StoreFile. |
| -r registryLocation | Identifies the registry location of the system certificate store. Meaningful only when s is set. Must be set to either currentUser or localMachine. CurrentUser is the default. currentUser means that the certificate store is under the registry key HKEY_CURRENT_USER, localMachine means HKEY_LOCAL_MACHINE. |
| -? | Displays all the options. |
View certificates, CRLs, and CTLs from a file called myFile.ext. myFile can be one of the following files: an encoded CTL, CRL, or certificate file (could be base64 encoded), a PKCS#7 file, an SPC file, a signed document, or a serialized storeFile.
CertMgr myFile.ext
View a system store called my store:
CertMgr -s my
Add all the certificates in a file called myFile.ext to a new file, called newFile.ext:
CertMgr -add -all -c myFile.ext newFile.ext
Copy all the certificates in a system store to a file called newMy.ext:
CertMgr -add -all -c -s my newMy.ext
Move a certificate with common name myCert in my system store to a file called newCert.cer:
CertMgr -add -c -n myCert -s my newCert.cer
Delete all the certificates in my system store:
CertMgr -del -all -c -s my
Delete all the CTLs in my system store and save the resulting store to a file called newStore.str:
CertMgr -del -all -ctl -s my newStore.str
The following example demonstrates how to build a CTL and move it to the root store:
// 1. Make a self-signed certificate called sign.cer. MakeCert -sv sign.pvk -r -n "CN=THIS IS A TEST OF MAKECTL" sign.cer // Make an SPC file using Cert2SPC. Cert2SPC sign.cer sign.spc // 2. Make another self-signed certificate called test.cer. MakeCert -sv test.pvk -r -n "CN=THIS IS MY TEST CERT" test.cer // Make an SPC file using Cert2SPC. Cert2SPC test.cer test.spc // 3. Make a test.ctl from test.cer. MakeCTL test.cer test.ctl // 4. Sign test.ctl with the sign.pvk and sign.spc made in step 1. SignCode -v sign.pvk -spc sign.spc test.ctl // 5. Move test.ctl to the trust system store. CertMgr -add -ctl test.ctl -s trust // 6. Move sign.cer to the root system store. CertMgr -add -c sign.cer -s root // 7. Sign something (test.exe) with test.pvk, and test.spc. SignCode -v test.pvk -spc test.spc test.exe // 8. Since test.cer is in the test.ctl, ChkTrust will succeed. ChkTrust test.exe
The SetReg utility is used to set the value of the registry keys controlling the behavior of the Authenticode certificate verification process. These keys are called the Software Publishing State Keys. When SetReg has completed the requested action, the current state of the Software Publishing State Keys is displayed.
The syntax for invoking SetReg is:
SetReg [options] [Choice # <True | False>]
The options can be one of the following values:
| For IE 4.0 | For IE 3.02 UPD | Description |
| -q | -q | Suppresses the display of the Software Publishing State Key values after SetReg has completed the requested action. The values are displayed by default. |
| -? | -h | Lists command syntax and options. |
Choice # must be one of the following values (valid for both IE 3.02 and IE 4.0, except 9 and 10, which are for IE 4.0 only):
| 1 | Trust the Test Root. Causes the test root to be a trusted root if set to TRUE. This is equivalent to running "regedit wvtston.reg" in Internet Explorer 3.x. The default is FALSE. Any code signed with a test root will not verify unless this flag is turned TRUE. |
| 2 | Use expiration date on certificates. Causes the certificate expiration date to be checked if set to TRUE. To ignore expiration dates, set this flag to FALSE. The default is TRUE. |
| 3 | Check the revocation list. Causes the revocation check to be performed if set to TRUE. To bypass revocation check, set this flag to FALSE. The default is FALSE in Internet Explorer 3.x and TRUE in Internet Explorer 4.x. |
| 4 | Offline revocation server OK (Individual). Allows off-line approval for individual certificates if set to TRUE. The default is FALSE. |
| 5 | Offline revocation server OK (Commercial). Allows off-line approval for commercial certificates if set to TRUE. The default is FALSE. |
| 6 | Java offline revocation server OK (Individual). Allows off-line approval for individual certificates and does not display the user interface for bad certificates if set to TRUE. The default is FALSE. |
| 7 | Java offline revocation server OK (Commercial). Allows off-line approval for commercial certificates and does not display the user interface for bad certificates if set to TRUE. The default is FALSE. |
| 8 | Invalidate version 1 signed objects. Invalidates version 1 signed objects if set to TRUE. The default is FALSE. |
| 9 | Perform the revocation check on the timestamp server's certificate if set to TRUE. The default is FALSE. For IE 4.0 only. |
| 10 | Only allow downloads from publishers that are contained in the Personal Trust Database if set to TRUE. The default is FALSE. For IE 4.0 only. |
Here is an example:
SetReg 1 TRUE
This turns on the capability to trust the test root.
© 1997 Microsoft Corporation. All rights reserved. Terms of Use.