In order to run a compiled WinBatch EXE, that contains Control Manager Extender functions, on a Windows System with UAC enabled requires that the 'uiAccess flag' is set to true and that the EXE is 'Signed' by a 'Trusted Authority'. In addition, if you do not sign your exes then Windows Vista or newer makes your program to appear as if it's a malware or a virus program. When you run an EXE, you may receive a message asking you whether or not you trust the application you are about to run. If your EXE is not digitally signed then the Popup message will reference an "Unknown Publisher". If the EXE is digitally signed it will reference your own information in the Popup message. NOTICE: Down the road, the Operating Systems will require any EXE, regardless of functionality, running under UAC, to be signed and trusted.
What is a certificate?Code Signing certificates allow you to 'digitally sign' your exes for secure delivery of your software. By digitally signing your EXE you are letting the user know the software is safe. To create a digital signature you will need 'a key pair'. A public key and a private key. The private key is known only to its owner (you) and is used to sign the data. The public key can be distributed to anyone and is used to verify the signature on the data. Digital certificates bind YOU to the specific public and private key pair. Digital certificates are like an electronic ID that verifies your identity. You can obtain a certificate from a certificate authority (CA), which vouches for the certificate. A CA generally requires you to provide unique identifying information. The CA uses this information to authenticate your identity before giving you a certificate.
Sources for digital certificates
Where do I buy a Certificate?There are many different Certificate Authorities (i.e., VeriSign and Thawte). For a more complete list check out 'Microsoft Root Certificate Program Members' list: http://msdn2.microsoft.com/en-us/library/ms995347.aspx
Buying a CertificateWinBatch itself has been signed using the Certification Authority 'Thawte'. Here are the steps to buy your own 'Code Signing' 'Digital Certificate'. Go to https://www.thawte.com/ssl-digital-certificates/code-signing/index.html. Follow all of the prompts. Here are some of the things you may be asked for:
Note: Your certificate issuer may require your private key (.pvk file) be stored on a special USB device or a secure "Cloud" server. Once you have completed the purchasing process you will be given a 'certificate request code' and a 'payment reference number'. You will then receive an email confirming your order. Next you will receive an email asking you to confirm that you approve the digital certificate order and it asks you to start the final verification step by clicking on a link. You then simply follow all of the various prompts at 'Thawte Automated Order Verification' website. To complete the 'automated' verification, you must:
This automated process, places a call to the first phone number you specified and the web page gives you a special 4 digit value to enter from your phone. Next the automated voice message gives you another 4 digit number called a "PIN" number that you will enter when the next call is received. Once you hang up you will receive another phone call to the other phone number and you will be asked to enter the PIN number. Once this is complete the web page will notify you that The following steps are still in progress: 'Proof of Domain Registration'. Finally you will receive an email telling your application for a Thawte certificate has been successful. It will contain a link to a web page where you can download your public certificate. Make sure to have your Thawte Account password handy. Confirm that your certificate is Microsoft Authenticode Format. I recommend downloading your public certificate to the same directory you stored your private.
Backing Up CertificatesPlease keep copies of the .pfx or the .pvk and .spc files in a safe place. If you lose your .pfx or .pvk file you will not be able to sign any code and will have to purchase a new certificate.
Install Microsoft Authenticode certificateNow you need to install your certificate. The process to install the certificate depends on the certificate file type. .PFX Certificate File Windows 7 and newer has a certificate installation wizard that can be invoked by simply double clicking on the .pfx file. Using the Wizard, installing a code signing certificate can be done in less than a minute. .SPC and .PVK Certificate Files In order to move your certificate and private key to the registry, Microsoft has created a tool called PVKIMPRT, which can be used to copy the .spc and .pvk files to the registry. Moving the certificate and private key to the registry allows you to sign your WinBatch exes. Download the PVK Digital Certificate Files Importer: Please read the usage instructions after downloading PVKIMPRT from Microsoft. The PVKIMPRT.EXE file that you downloaded from Microsoft is a self-extracting archive which, when executed without any options, will install the real 'PVKIMPRT.EXE' into a directory on your path. WinBatch offers a script to handle the install and import for you. The InstallCodeSignCertificate.wbt located in your WinBatch\Samples subdirectory. Note: this script requires that you have already downloaded and installed the PVKIMPRT.EXE from Microsoft. Otherwise you can use PVKIMPRT via the windows command line. Go to the START | Run menu CMD.EXE then type:
C:\WINDOWS\PVKIMPRT.EXE -IMPORT "{SPC file path}" "{PVK file path}"
How do I know if the Certificate is installed?You have a few options to determine whether or not a certificate has been successfully installed. Using Certmgr.msc CertMgr is a Microsoft Management Console (MMC) snap-in that Allows you to view and manage information about certificates, such as certificate contents and the certification path. It also allows you to specify the friendly name for a certificate. Using Internet Explorer
Give the Certificate a Friendly NameYou can view and manage the root certificates and code signing certificates on your computer by using Certmgr.msc. Locate your desired code signing certificate under the Personal/Certificates and click View and then the Details tab. Select the Friendly Name field and click Edit Properties. There you can change the Friendly Name. Sign code with Microsoft Authenticode CertificateOnce the certificate is correctly installed, you should be able to sign your EXE. You have a few options for signing your WinBatch EXEs:
Timestamp an .EXE fileTimestamping ensures that code will not expire when the certificate expires. Digicert offers a timestamping service http://timestamp.Digicert.com . We recommend that you specify Digicert’s timestamp server url when you sign the WinBatch EXE file. The timestamp server validates the date and the time that the file was signed therefore the certificate can expire but the signature will be valid for as long as the file is in production. A new certificate is only necessary if you want to sign additional code or re-sign code that has been modified. If you do not use the timestamping option during the signing, you must re-sign your code and re-send it out. To verify if your file has been timestamped, use the chktrust.exe utility included with the Authenticode SDK tools. The date and time will be displayed when the file has been timestamped. "Unknown date and time" will appear when the file has NOT been timestamped. The WinBatch Compiler and InstallCodeSignCertificate.wbt both use this timestamp server when signing code for you. However if you choose to use IntControl 93 or SignCode.exe to sign your EXEs then you should specify this time server. Hopefully this will help step you through the harrowing process of purchasing a Code signing certificate, installing it and signing your very first WinBatch EXE. Good Luck!
Special note for Windows 8/2012 R2 and newer versions of Windows: There is a "Use RFC 3161 Timestamp" option to the "Code Signing Details" dialog. When this option is checked the compiler will timestamp the executable using a RFC-3161-compliant timestamp server and the more secure SHA-256 hash algorithm. When this option is not checked the compiler will use an Authenticode timestamp server and the SHA-1 hash algorithm to timestamp the executable file. This option is enabled when the compiler is executing on Windows 8/2012 R2 and newer versions of Windows. It is disabled on older versions of Windows because older platforms lack the functionality necessary to support RFC-3161-compliant timestamp servers for timestamp operations. Windows Vista/2008 cannot process RFC-3161-compliant timestamps and will consider applications timestamped using an RFC-3161-compliant timestamp server untrusted. Windows 7/2008R2 and newer versions of Windows trust executables timestamped using an RFC-3161-compliant timestamp server. As mentioned in IntControl 93 p1=3 option notes, Microsoft states that, "Long-term, Microsoft intends to distrust SHA-1 throughout Windows in all contexts. Microsoft is closely monitoring the latest research on the feasibility of SHA-1 attacks and will use this to determine complete deprecation timelines." The Digicert timestamp service requires setting the "Use RFC 3161 Timestamp" option.
FAQsIs there a limit to the number of applications that are allowed to be signed with a Code Signing Certificate? No, it should not limit you to any specific number. You can sign as many WinBatch exes with a Code Signing Certificate as you wish, provided that the applications are used for and distributed by the organization that owns the certificate. How long can I use a Code Signing Certificate for? Code Signing Certificates are valid for 1 or 2 years depending on which life cycle you choose when you purchase the certificate. Please note: For Microsoft Authenticode, you should also timestamp your signed code to avoid your code expiring when your certificate expires. (You timestamp your EXE when you 'sign' it). Is timestamped code valid after a Code Signing Certificate expires? Microsoft Authenticode allows you to timestamp your signed code. Timestamping ensures that code will not expire when the certificate expires because the browser validates the timestamp. The timestamping service is provided courtesy of VeriSign. If you use the timestamping service when signing code, a hash of your code is sent to VeriSign’s server to record a timestamp for your code. A user’s software can distinguish between code signed with an expired certificate that should not be trusted and code that was signed with a Certificate that was valid at the time the code was signed but which has subsequently expired. Please specify VeriSign’s timestamp server url when you sign the WinBatch EXE file. The timestamp server validates the date and the time that the file was signed therefore the certificate can expire but the signature will be valid for as long as the file is in production. A new certificate is only necessary if you want to sign additional code or re-sign code that has been modified. If you do not use the timestamping option during the signing, you must re-sign your code and re-send it out. To verify if your file has been timestamped, use the chktrust.exe utility included with the Microsoft Authenticode SDK tools. The date and time will be displayed when the file has been timestamped. "Unknown date and time" will appear when the file has NOT been timestamped. You can use the Verisign timestamping server by adding "-t http://timestamp.verisign.com/ scripts/timstamp.dll to the 'signcode' command line.
Enter a Password for the Private Key It is very important that you remember the password when your browser generates this private key. Failure to remember the password will result in a complete inability to use the Certificate, and you will need to re-issue your Certificate free of charge. However, having password protection on the private key requires that you enter the password every time you 'sign' an object. If you are going to automate the signing procedure, you can choose not to have password protection on the private key. Click on the "None" button to do without a password. This is a big security risk, and is not recommended
Known Issues Microsoft has published information about a known bug in the signcode and pvkimprt utilities they currently make available to clients. This vulnerability will only be addressed in the release of Windows XP. When clients attempt to move certificates and keys between e.g. Windows NT and Windows ME or Windows XP, they may encounter problems when importing the files into the registry. This is caused by a default key length discrepancy between the platforms. For further information about this bug, please refer to the article published on Microsoft?s website at the following url, http://www.microsoft.com/mind/0299/faq/faq0299.asp
|
Code Signing |