I saw that you got a few responses to your question, but this has been asked many times before yet never fully answered to satisfaction. So here is the complete explanation, which will probably be much more than you want to know about this subject. Nonetheless, I thought it would be nice to set the record straight on this.
The confusion here is that we are talking about two TOTALLY DIFFERENT types of signatures: code signing (i.e., Authenticode) vs. WHQL driver signing. The first one, code signing, is used to authenticate the author of an executable. The second is to ensure that a particular driver has been certified for use with Windows 2000 or Windows XP. With code signing, credentials are attached to a binary using an individual's or organization's digital certificate. These credentials can be verified by looking at the file properties and selecting the Digital Signatures tab or using the chktrust.exe tool that is included with the Platform SDK and the .NET Framework SDK. With code signing, the signature credentials actually become part of the binary file. If you open the file in a hex editor you will see the actual signature near the end of the file. WHQL driver signing, on the other hand, is when Microsoft verifies that a driver has been tested to be compatible with Windows 2000 or XP and that the files have not changed since testing. Driver signatures are included in a catalog file (*.CAT) that is distributed with the driver. When Windows checks a driver signature, it checks the catalog file to make sure the drivers have not been altered. The individual files are not signed, but the .CAT file itself is signed with Microsoft's certificate (using the code signing method mentioned above). Driver signing only verifies that those particular files have been tested to be compatible with Windows 2000 or XP. Driver signatures can be verified with the sigverif.exe tool or driverquery.exe that comes with Windows XP. The primary difference between the two is that code signing is done on each binary file with the author's certificate whereas with driver signing, only the catalog file is signed and that is done with Microsoft's certificate. Code signing is to verify the authenticity of a file while driver signing is more intended for system reliability. So when you get the message box saying that the driver files have not been signed, it does not mean that the hotfix itself has not been signed. If you look at the signature properties or use the chktrust.exe tool, you will see that indeed, the file has been signed and is valid. However, when the hotfix installs it uses the SetupCopyOEMInf function which triggers the checking of driver signatures. Windows then looks at the hotfix.inf file to determine the name of the catalog file. That catalog file name should appear in hotfix.inf under the [Version] section like this: [Version] CatalogFile=sp3.cat Windows then looks for that catalog file (in this case sp3.cat) to verify the digital signature (which will be Microsoft's signature). If that passes, it verifies the checksums (one MS document calls them checksums, another MS document calls them hashes) of each hotfix file against the checksums (or hashes) in the catalog file. Since hotfixes do have the catalog file entry in the hotfix.inf and that catalog file (sp3.cat) is included in the with the hotfix distribution, you'd thing that it would pass driver signature checking. But it doesn't. There are two reasons why the driver signature checking is failing at installation: either the drivers themselves are bad or it cannot find the catalog file to verify the signatures. Once you install the hotfix you can run the sigverif tool and see that the driver files are indeed verified at that point so it isn't because the drivers are bad. The only explanation is that it cannot find the catalog file during installation. I did quite a bit of research to find out exactly why this was happening and found one possible reason that I have not verified myself nor have I informed Microsoft before this e-mail. In the Code Signing FAQ located at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnw2k /html/win2ksignfaq.asp, it says that in addition to adding a CatalogFile= entry in the .INF, you must also add the .CAT file in the [SourceDiskFile] section. I noticed that hotfix.inf doesn't have this entry, so perhaps that is why it is failing. Again, this has not been verified. Another issue is the KB article Q269651. This article suggests that you should set unsigned driver behaviour to silently succeed. I would NOT recommend this setting, but would suggest to have it warn you instead. In my opinion, this KB article should be changed. In Windows 2000, the default setting is to warn but still allow installation. And how is this setting changed? There are a number of ways: 1. From the Control Panel, open the System applet, select the Hardware tab and click on the Driver Signing button. 2. From the Administrative Tools, select one of the Security Policy snap-ins and change the Unsigned driver installation behaviour under Local Policies/Security Options. 3. Create a Group Policy and change the setting under Local Computer Policy\Computer Configuration\Windows Settings\Security Settings\Local Settings\Security Options. 4. Create or modify the values for BehaviorONFailedVerify and Policy under HKLM\Software\Policies\Microsoft\Windows NT\Driver Signing. 5. Create or modify the values for BehaviorONFailedVerify and Policy under HKCU\Software\Policies\Microsoft\Windows NT\Driver Signing. 6. Create the policy in a security template. So as you see, the message you get that says that the software you are trying to install is not signed is misleading. First of all, it has nothing to do with the validity of the hotfix file you downloaded. Second, it turns out that the hotfix files actually are signed but the hotfix installation is not recognizing this. I'd say this is a bug that should be fixed. Another important thing to note is that there is no automatic checking of the hotfix's signature itself. If you download a corrupted or malicious hotfix, there will be no warning when you run it. You MUST manually verify every hotfix's signature before installing. One interesting thing I just found while writing this is that the Digital Signature tab in the file properties may not always be correct. I opened up Q314147_W2K_SP3_X86_EN.exe in a hex editor and randomly changed data in the binary file. I saved this and looked at the signature properties. The Name of Signers field now said "Not available" but when I looked at the certificate details it said that the digital signature is OK, which was obviously incorrect. When I verified that same file with chktrust using the command chktrust.exe -v -q Q314147_W2K_SP3_X86_EN.exe I got the following message: Q314147_W2K_SP3_X86_EN.exe: Failed: The subject is not trusted for the specified action So perhaps the you cannot trust the Digital Signatures tab in the file properties. Another thing to consider is what this all means when doing unattended installs. When including hotfixes during unattended installation, you may be forced to set the DriverSigningPolicy setting to ignore in the unattend.txt file. Just be sure to properly set the policy after installation. So in summary: 1. Hotfix signatures are not automatically verified, but can manually be verified with chktrust.exe 2. The Digital Signature tab in the file properties dialog may not be trustworthy 3. The invalid signature message during installation has nothing to do with the hotfix download itself 4. The invalid signature message is wrong, and you can verify the signatures after installation with sigverif.exe 5. Microsoft might be able to fix this error message by checking on that SourceDiskFile thing 6. Q269651 has a poor recommendation to set your system to silently install unsigned drivers And of course, previous recommendations to get the root certificates update are also a good idea. Mark Burnett www.xato.net On Thu, 21 Feb 2002 16:32:15 +0800, [EMAIL PROTECTED] wrote: > >Hi, > >Recently, when I try to download patches from Microsoft I get the >messages "Unknown Software Package", "The Software you are trying to >install is not signed." "Microsoft cannot guarantee that this >software will work with Windows." etc. > >Is this just temporary or is this the extension of the Mircrosoft >"We-don't-test-our-software-and-don't-guarantee-it-is-working-and-if >- >you-use-it-you-have-to-blame-only-yourself-Policy" > >towards the patches? > >What is safer, install no patches or install unsigned patches? > >Cheers, Andreas > >
