1. Microsoft Authenticode Root Authority Expired

Mar 22, 2011 In today’s post, I’ll be discussing the use of Authenticode to sign software programs; this post will be of interest primarily to software developers. My computer which is new has a code which shows valid from: 1/1/1995 to, and it also states this certificate has expired or is not yet Valid.

How to: Create Temporary Certificates for Use During Development. 4 minutes to read. Contributors. In this article When developing a secure service or client using Windows Communication Foundation (WCF), it is often necessary to supply an X.509 certificate to be used as a credential. The certificate typically is part of a chain of certificates with a root authority found in the Trusted Root Certification Authorities store of the computer. Having a certificate chain enables you to scope a set of certificates where typically the root authority is from your organization or business unit.

To emulate this at development time, you can create two certificates to satisfy the security requirements. The first is a self-signed certificate that is placed in the Trusted Root Certification Authorities store, and the second certificate is created from the first and is placed in either the Personal store of the Local Machine location, or the Personal store of the Current User location.

This topic walks through the steps to create these two certificates using the, which is provided by the.NET Framework SDK. Important The certificates the Certification Creation tool generates are provided for testing purposes only. When deploying a service or client, be sure to use an appropriate certificate provided by a certification authority. This could either be from a Windows Server 2003 certificate server in your organization or a third party.

By default, the creates certificates whose root authority is called 'Root Agency.' Because the 'Root Agency' is not in the Trusted Root Certification Authorities store, this makes these certificates insecure. Creating a self-signed certificate that is placed in the Trusted Root Certification Authorities store enables you to create a development environment that more closely simulates your deployment environment.

For more information about creating and using certificates, see. For more information about using a certificate as a credential, see. For a tutorial about using Microsoft Authenticode technology, see. To create a self-signed root authority certificate and export the private key. Use the MakeCert.exe tool with the following switches:.n subjectName. Specifies the subject name.

The convention is to prefix the subject name with 'CN = ' for 'Common Name'. Specifies that the certificate will be self-signed.sv privateKeyFile. Specifies the file that contains the private key container.

For example, the following command creates a self-signed certificate with a subject name of 'CN=TempCA.' Makecert -n 'CN=TempCA' -r -sv TempCA.pvk TempCA.cer You will be prompted to provide a password to protect the private key. This password is required when creating a certificate signed by this root certificate. To create a new certificate signed by a root authority certificate. Use the MakeCert.exe tool with the following switches:.sk subjectKey. The location of the subject's key container that holds the private key.

If a key container does not exist, one is created. If neither of the -sk or -sv options is used, a key container called JoeSoft is created by default.n subjectName. Specifies the subject name. The convention is to prefix the subject name with 'CN = ' for 'Common Name'.iv issuerKeyFile. Specifies the issuer's private key file.ic issuerCertFile. Specifies the location of the issuer's certificate. For example, the following command creates a certificate signed by the TempCA root authority certificate with a subject name of 'CN=SignedByCA' using the private key of the issuer.

Makecert -sk SignedByCA -iv TempCA.pvk -n 'CN=SignedByCA' -ic TempCA.cer SignedByCA.cer -sr currentuser -ss My Installing a Certificate in the Trusted Root Certification Authorities Store Once a self-signed certificate is created, you can install it in the Trusted Root Certification Authorities store. Any certificates that are signed with the certificate at this point are trusted by the computer. For this reason, delete the certificate from the store as soon as you no longer need it. When you delete this root authority certificate, all other certificates that signed with it become unauthorized. Root authority certificates are simply a mechanism whereby a group of certificates can be scoped as necessary. For example, in peer-to-peer applications, there is typically no need for a root authority because you simply trust the identity of an individual by its supplied certificate.

To install a self-signed certificate in the Trusted Root Certification Authorities. Open the certificate snap-in.

For more information, see. Open the folder to store the certificate, either the Local Computer or the Current User. Open the Trusted Root Certification Authorities folder. Right-click the Certificates folder and click All Tasks, then click Import.

Follow the on-screen wizard instructions to import the TempCa.cer into the store. Using Certificates With WCF Once you have set up the temporary certificates, you can use them to develop WCF solutions that specify certificates as a client credential type. For example, the following XML configuration specifies message security and a certificate as the client credential type. To specify a certificate as the client credential type. In the configuration file for a service, use the following XML to set the security mode to message, and the client credential type to certificate. In the configuration file for a client, use the following XML to specify that the certificate is found in the user’s store, and can be found by searching the SubjectName field for the value 'CohoWinery.' For more information about using certificates in WCF, see.NET Framework Security Be sure to delete any temporary root authority certificates from the Trusted Root Certification Authorities and Personal folders by right-clicking the certificate, then clicking Delete.

Signing and Checking Code with Authenticode. 36 minutes to read In this article This section demonstrates how to sign code by creating digital signatures and associating them with files using Microsoft Authenticode technology. Creating a fully verifiable certificate might assume the existence of a complex hierarchy of certification authorities. A root certificate and a root private key are provided for testing purposes only. Independent software vendors (ISVs) must obtain a certificate from a certification authority that is trusted by default in Windows.

(For a list of trusted certification authority (CA) see.) Authenticode consists of programs for digitally signing code files as well as programs for checking that the code files were successfully signed. Viber software for nokia 5800. Currently, Authenticode allows software vendors to sign:.cab files.cat files.ctl files.dll files.exe files.ocx and The Authenticode programs are:. MakeCert, which creates a test X.509 certificate. Cert2SPC, which creates a test software publishing certificate. SignCode, which signs a file. ChkTrust, which checks the validity of the file.

MakeCTL, which creates a certificate trust list. CertMgr, which manages certificates, certificate trust lists, and certificate revocation lists. SetReg, which sets registry keys that control the certificate verification process.

MakeCat, which creates a combined catalog of files to avoid multiple trust dialogs in Microsoft Internet Explorer 5 and later. MakeCat is described in. Note All user input to these programs is now case-insensitive. Additionally, separate options now exist for the key-pair name and the private-key file.

MakeCert Use the MakeCert test program to generate a test X.509 certificate. MakeCert performs the following tasks:. Creates a public/private key pair for digital signatures and associates it with a name that you choose. Associates the key pair with a publisher's name that you choose. Creates an X.509 certificate, signed by the test root key or one you specify, that binds your name to the public part of the key pair. The certificate is output to a file, a system certificate store, or both. The syntax for invoking MakeCert is: MakeCert basic options extended options outputFile MakeCert's options consist of basic options and extended options.

Basic options are the most commonly used to create a certificate. Extended options provide more flexibility. The options for MakeCert are also divided into three functional groups:. Options applicable to software publishing certificate-file, private-key, and certificate store technology. Options specific to software publishing certificate-file and private-key technology only. Options specific to certificate store technology only.

Options in groups 2 and 3 cannot be mixed, with the exception of the -ic option. MakeCert Group 1 Options The following group 1 options may be applied in all cases: Options are sorted alphabetically in the left (Microsoft Internet Explorer 4.0 and later) column, and the corresponding Microsoft Internet Explorer 3.02 options are given in the middle column.

Internet Explorer 3.02 options that have no direct equivalent in Internet Explorer 4.0 or later will say either ' N/A' or '(See - option)' in the column for Internet Explorer 4.0 and later, and are sorted alphabetically into the order of options for Internet Explorer 4.0 and later. For example, the Internet Explorer 3.02 -C option follows the -b option for Internet Explorer 4.0 and later. Internet Explorer 4.0 and later Internet Explorer 3.02 UPD Description -a algorithm -a For Internet Explorer 3.02: Indicates the SHA1 hash algorithm should be used. MD5 is the default For Internet Explorer 4.0 and later: The hash algorithm. Must be set to either SHA1 or MD5. The default is MD5.b dateStart -B: dateStart The date the certificate first becomes valid. The default is when the certificate is created.

The format of dateStart is mm/dd/yyyy. (See -$) -C The certificate will be used by commercial software publishers. (See -$) -C: f The certificate will be used by commercial software publishers who have met the minimum financial criteria.cy certificateTypes -t: types For Internet Explorer 3.02: The certificate type.

This parameter can be E for end-entity, C for certificate authority, or both. For Internet Explorer 4.0 and later: The certificate type. Can be end, authority, or both. End stands for end-entity and authority stands for certificate authority.d displayName -d: displayName The display name of the subject.e dateEnd -E: dateEnd The date when the validity period ends. The default is the year 2039.eku OID1,OID2. N/A Inserts a list of one or more comma-separated enhanced key usage Object Identifiers (OIDs) into the certificate.

For example, -eku 1.3.6.1.5.5.7.3.2 inserts the client authentication OID. See wincrypt.h in the documentation for definitions of allowable OIDs. N/A -g Creates a glue certificate (Internet Explorer 3.02 only.) -h numChildren -h: numChildren The maximum height of the tree below this certificate.

(See -$) -I The certificate will be used by individual software publishers.l policyLink -l: policyLink A link to software publishing certificate agency policy information—for example, a URL.m nMonths -D: nMonths The duration of the validity period. (See -a) -m The MD5 hash algorithm should be used. This is the default.n name -n: name The name for the publisher's certificate. This name must conform to the X.500 standard. The simplest method is to use 'CN= MyName' format.

For example: -n 'CN=Test'.nscp -N The Netscape client authentication extension should be included. r -r Creates a self-signed certificate.sc subjectCertFile -U: subjectCertFile The certificate file name with the existing subject public key to be used.sk subjectKey -u: subjectKey The location of the subject's key container which holds the private key. If a key container does not exist, one is created. If neither of the -sk or -sv options are used, the JoeSoft key container is created and used by default.sky subjectKeySpec N/A The subject's key specification, which must be one of three possible values: 1. Signature, which stands for ATSIGNATURE key specification. Exchange, which stands for ATKEYEXCHANGE key specification. An integer, such as 3.

See notes on key specifications below.sp subjectProviderName N/A CryptoAPI provider for subject. The default is the user's provider. See the documentation for details on CryptoAPI providers.sr subjectCertStoreLocation N/A The registry location of the subject's certificate store.

Must be either localMachine or currentUser. CurrentUser is the default. CurrentUser means that the certificate store is under the registry key HKEYCURRENTUSER and localMachine means HKEYLOCALMACHINE.ss subjectCertStoreName N/A The name of the subject's certificate store where the generated certificate will be stored.sv subjectKeyFile -k: subjectKeyFile The location of the subject's.pvk file. If neither of the -sk or -sv options are used, the JoeSoft key container is created and used by default.sy nSubjectProviderType N/A CryptoAPI provider type for subject. The default is PROVRSAFULL. See the documentation for details on CryptoAPI provider types.# serialNumber -#: serialNumber The serial number of the certificate.

The maximum value is 2^31. The default is a value generated by the program that is guaranteed to be unique.$ certificateAuthority (See -I, - C, - C:f) The type of Certificate Authority. Must be set to either commercial or individual.

Commercial means the certificate will be used by commercial software publishers. Individual means the certificate will be used by individual software publishers. Displays the basic options. N/A Displays the extended options. If the -sky key specification option is used in Internet Explorer 4.0 and later, the specification must match the key specification indicated by the private key file or private key container. If the key specification option is not used, then the key specification indicated by the private key file or private key container will be used. If there is more than one key specification in the key container, MakeCert will first attempt to use the ATSIGNATURE key specification.

If that fails, MakeCert will then try to use ATKEYEXCHANGE. Since most users have either an ATSIGNATURE key or ATKEYEXCHANGE key, this option does not need to be used in most cases. MakeCert SPC-file and Private-key Technology Options The following are group 2 options for software publishing certificate-file and private-key technology only: Internet Explorer 4.0 and later Internet Explorer 3.02 UPD Description -ic issuerCertFile -i: issuerCertFile The location of the issuer's certificate.ik issuerKey -s issuerKeyFile The location of the issuer's key container. The default is the test root key.iky IssuerKeySpec -K: keySpec For Internet Explorer 3.02: The issuer's key specification. This parameter can be either S for a signature key (this is the default) or E for a key-exchange key.

For Internet Explorer 4.0 and later: The issuer's key specification, which must be one of three possible values: 1. Signature, which stands for ATSIGNATURE key specification. Exchange, which stands for ATKEYEXCHANGE key specification. An integer, such as 3.

See notes on key specifications below.ip IssuerProviderName -x: providerName CryptoAPI provider for issuer. The default is the user's provider. See the documentation for details on CryptoAPI providers.iv issuerKeyFile -s: issuerKeyFile The issuer's private-key file.

The default is the test root.iy nIssuerProviderType -y: nProviderType CryptoAPI provider type for issuer. The default is PROVRSAFULL. See the documentation for details on CryptoAPI provider types. If the -iky key specification option is used in Internet Explorer 4.0 and later, the specification must match the key specification indicated by the private key file or private key container. If the key specification option is not used, the key specification indicated by the private key file or private key container will be used. If there is more than one key specification in the key container, MakeCert will first attempt to use the ATSIGNATURE key specification.

If that fails, MakeCert will then try to use ATKEYEXCHANGE. Since most users have either an ATSIGNATURE key or ATKEYEXCHANGE key, this option does not need to be used in most cases. MakeCert Certificate Store Technology Options The following are group 3 options for certificate store technology only: Internet Explorer 4.0 and later Internet Explorer 3.02 UPD Description -ic issuerCertFile NA The file containing the issuer's certificate. For Internet Explorer 4.0 and later, MakeCert will search in the certificate store for a certificate with an exact match.in issuerNameString N/A The common name of the issuer's certificate. MakeCert will search in the certificate store for a certificate whose common name includes issuerNameString.ir IssuerCertStoreLocation N/A The registry location of the issuer's certificate store. Must be either localMachine or currentUser.

CurrentUser is the default. CurrentUser means that the certificate store is under the registry key HKEYCURRENTUSER and localMachine means HKEYLOCALMACHINE.is issuerCertStoreName N/A The issuer's certificate store that includes the issuer's certificate and its associated private key information.

If there is more than one certificate in the store, the user must uniquely identify it with the -ic or -in option. If the certificate in the certificate store is not uniquely identified, MakeCert will fail. MakeCert Internet Explorer 3.02 UPD Example The following is an example that creates a certificate using the Internet Explorer 3.02 UPD options: MakeCert -k:c: KeyStore MyKey.pvk -n:CN=MySoftwareCompany Cert.cer In this example, a certificate file called Cert.cer is created. The public part of the key pair called MyKey is bound to the publisher, MySoftwareCompany. 6.4 MakeCert Examples for Internet Explorer 4.0 and later The following are a series of examples for creating certificates with MakeCert using the options for Internet Explorer 4.0 and later. Make a certificate issued by the default test root.

Save the certificate to a file. MakeCert myNew.cer Make a certificate issued by the default test root. Save it to a certificate store. MakeCert -ss myNewStore Make a certificate issued by the default test root. Create a.pvk file and output the certificate to both a store and a file.

Microsoft Authenticode Root Authority Expired

MakeCert -sv myNew.pvk -ss myNewStore myNew.cer Make a certificate issued by the default test root. Create a key container and output the certificate to both a store and a file. MakeCert -sk myNewKey -ss myNewStore myNew.cer Make a certificate using the default test root. Save the certificate to a store. Then make another certificate using the newly created certificate. Save the second certificate to another store. MakeCert -sk myNewKey -ss myNewStore MakeCert -is myNewStore -ss anotherStore Make a certificate using the default test root.

Save the certificate to my store. Then make another certificate using the newly created certificate. Because there is more than one certificate in my store, identify the first certificate using its common name. MakeCert -sk myNewKey -n 'CN=XXZZYY' -ss my MakeCert -is my -in 'XXZZYY' -ss anotherStore Make a certificate using the default test root. Save the certificate to my store and to a file. Then make another certificate using the newly created myNew certificate.

Because there is more than one certificate in my store, uniquely identify the first certificate using the certificate file name. MakeCert -sk myNewKey -n 'CN=XXZZYY' -ss my myNew.cer MakeCert -is my -ic myNew.cer -ss anotherStore Create a self-signed certificate named myNewRoot using the default test root. Then use SignCode with the certificate to sign a file. MakeCert -sk myNewRootKey -r -ss myNewRoot SignCode -s myNewRoot myControl.exe Create a self-signed certificate named myNewRoot using the default test root. Save myNewRoot into a system certificate store ca.

Then make a certificate from myNewRoot and sign some code with the certificate. When SignCode uses a certificate in a store for signing, it will also build a certificate chain from the signing certificate to a root.

All of the certificates in the certificate chain must be in any of the my, ca, spc, or root certificate stores. In this case, myNewRoot is in the ca certificate store. MakeCert -sk myNewRootKey -r -ss ca myNewRoot.cer MakeCert -is ca -ic myNewRoot.cer -ss myNewSign SignCode -s myNewSign myControl.exe Cert2SPC After you have generated a certificate, you can create an software publishing certificate with the Cert2SPC program. This program wraps multiple X.509 certificates into a public key certificate standard (PKCS) #7 signed-data object. Note that this program is for test purposes only. A valid software publishing certificate is obtained from a certificate authority. The syntax for Cert2SPC is: Cert2SPC cert1.cer cert2.cer.certN.cer output.spc In the previous syntax example:.

cert1. CertN are the names of the X.509 certificates to include in the software publishing certificate. output is the name of the PKCS #7 object containing the X.509 certificates. Here is an example: Cert2SPC MyCert.cer MyCert.spc This wraps an X.509 certificate, MyCert.cer into a PKCS #7 software publishing certificate called MyCert.spc.

SignCode The final step is to actually sign a file using the SignCode program. This program will:. Create a Cryptographic Digest of the file. Sign the digest with your private key. Copy the X.509 certificates from the software publishing certificate into a new PKCS #7 signed-data object. The PKCS #7 object contains the serial numbers and issuers of the certificates used to create the signature, the certificates, and the signed digest information. Embed the object into the file.

Optionally, it can add a time stamp to the file. A time stamp should always be added when signing a file. However, SignCode also has the ability to add a time stamp to a previously signed file subject to some restrictions (see the examples that follow the options table). The syntax for signing is: SignCode options fileName In the example, fileName is the name of the output file (Internet Explorer 4.0 and later) and options are as described below. The options for SignCode are divided into three groups:. Basic options applicable in all cases. Options specific to software publishing certificate-file and private-key technology.

Options specific to certificate store technology. Options in groups 2 and 3 cannot be mixed in the same operation.

SignCode Basic Options The following basic options (group 1) may be applied in all cases: Options are sorted alphabetically in the left (Internet Explorer 4.0 and later) column, and the corresponding Internet Explorer 3.02 options are given in the middle column. Internet Explorer 3.02 options that have no direct equivalent for Internet Explorer 4.0 and later will say either ' N/A' or '(See - option)' in the column for Internet Explorer 4.0 and later, and are sorted alphabetically into the order the options for Internet Explorer 4.0 and later. For example, the Internet Explorer 3.02 -individual option follows the -i option for Internet Explorer 4.0 and later. Internet Explorer 4.0 and later Internet Explorer 3.02 UPD Description -a algorithm -sha, -md5 The hashing algorithm to use. Must be set to either SHA1 or MD5.

The default is MD5. (See -$) -commercial The code being signed was created by a commercial software publisher. The action SignCode will take depends upon both this setting and the software publishing certificate actually used. See the table following these options for possible actions.i opusInfo -info opusInfo A location, such as a URL, for obtaining information about your program.

(See -$) -individual The code being signed was created by an individual software publisher. The action SignCode will take depends upon both this setting and the software publishing certificate actually used. See the table following these options for possible actions.j dllName N/A The name of a DLL that returns an array of authenticated attributes for signing files. The user can specify more than one DLL by repeating the -j option. For example: -j dll1 -j dll2 -j dll3 -jp dllParam N/A A parameter to be passed for the preceding DLL. For example: -j DLL1 -jp DLL1Param. Only one parameter is allowed per DLL.

For a list of predefined DLLs and their parameters, see -j and -jp SignCode Options. (See -a) -md5 Specifies that the MD5 hashing algorithm should be used. This is the default hashing algorithm.n opusName -name opusName The friendly name of your program. N/A -nocerts Specifies that no X.509 certificates should be embedded in the PKCS #7 signed-data object.

In this case, the relevant certificates must already be stored on the client computer. In Internet Explorer 4.0 and later, all certificates will always be included in the message. N/A -prog filename The output file name in Internet Explorer 3.02 UPD. In Internet Explorer 4.0 and later, the file name is always placed as the last item on the command line.

(See -a) -sha Specifies that the SHA1 hashing algorithm should be used.t httpAddress timestamper Indicates that the file is to be time stamped. A URL specifying an address of a time stamping server must be provided (see -x for time stamping previously signed files).tr times N/A The maximum number of time stamping trials. The default is 1. SignCode will repeat the time stamping operation until it is successful or the limit on number of trials is reached.tw seconds N/A The number of seconds between each time stamping trial.

The default is 0.x -nosigning Used when just time stamping a previously signed file. No signing is performed. Must be used in conjunction with -t.$ signingAuthority -commercial, -individual The type of publisher that created the code being signed. Must be either commercial or individual. The action SignCode will take depends upon both this setting and the signing certificate actually used. See the table following these options for possible actions.

Displays all of the options. The signature type (commercial or individual) used by SignCode depends on the signing option and certificate used. In some cases SignCode will fail the requested operation if there is a conflict.