I recently took on a task to update our filter driver from building with Visual Studio 2015 -> 2019. I also moved to the latest SDK + WDK 22000 (Which is the new Windows 11 one).
Everything seemed to work except that on Win 7 x64 (with secure boot) boxes the driver no longer loads.. It get's:
Load failed with error: 0x80070241
Windows cannot verify the digital signature for this file. A recent hardware or
software change might have installed a file that is signed incorrectly or damaged,
or that might be malicious software from an unknown source.
Our driver was/is attestation signed by Microsoft via the MS Hardware portal and so it's joint signed by both our company and Microsoft with a SHA-2 signature each. Windows 7 doesn't support SHA-2 certs out of the box however, it was previously working provided:
Windows6.1-KB3033929-x64
Was installed. Something seems to have changed though and Windows 7 x64 boxes can't load the new driver even with the latest updates. They load the 2015 built driver just fine even though the certificates on both look identical. The new driver loads just fine on Windows 10 machines.
Is anyone aware of any other changes which might make this combination fail to load?
I had a similar issue a few months ago, when we decided to switch our certificate provider. I'll share my knowledge to you, hope that going to help.
A while ago, Microsoft used cross-certificates to validate trusted certificate authorities (CA), so the only thing you needed to sign a driver is a proper certificate bought from a trusted CA. But recently validating process had changed and starting from Windows 10 20H2 you are forced to sign your driver through Microsoft Partner Center and all the cross-certificates was deprecated. However, you still need to use cross sign process for all your drivers prior to Windows 10, actually cross signed driver will work up to Windows 10 20H1 if to be correct.
Now back to the Visual Studio. To properly sign driver, you had to set up production certificate to field Properties -> Driver Signing -> General -> Production Certificate, that causes Visual Studio to use signtool utility to sign driver after the build done. As I presume, Visual Studio 2019 process do not use cross-certificate and looks something like:
signtool sign /v <trusted_certificate> /tr http://timestamp.digicert.com /td sha256 /fd sha256 /a <sys_driver_filepath>
But Visual Studio 2013 actually must use cross-certificate and the command it uses is:
signtool sign /v /ac <microsoft_cross_certificate> /tr http://timestamp.digicert.com /a <sys_driver_filepath>
So what is cross-certificate is? It's a special trusted Microsoft certificate that tied to certified CA. List of all the cross-certificates available can be found here https://learn.microsoft.com/en-us/windows-hardware/drivers/install/cross-certificates-for-kernel-mode-code-signing#cross-certificate-list. To take the correct one you need to check your company certificate first. Take a look into root of certification path of your cert, open View Properties -> Details and find Issuer, that's your CA. Now you need to find exact match on cross-certificate list and download it. Note the thumbprint doesn't need to match (revealed in related issue). After all use a proper signtool command to sign your file.
P.S. If your certificate issuer not present on the list, that means your CA inappropriate and you need to get/buy another certificate.
Related
I would like to know what is the impact of dropping SHA1 code signing in favour of SHA256-only code signing as of October 2018. I am currently dual code signing my executables to ensure they will get validated on all versions of Windows starting from Windows 7 / Windows Server 2008 R2. There are many articles online showing code signing requirement matrices, but it's not so clear how many environments in practice won't validate SHA256-only signatures. From what I understood, SHA256 code signing support came in an update in Windows 7, but I don't know if this update is widely installed.
The reason I am asking is because I know it is just a matter of time before SHA256 is supported on all versions of Windows that are not in their end of life, and I am considering using AzureSignTool (https://github.com/vcsjones/AzureSignTool) which doesn't support SHA1 code signing.
it's not so clear how many environments in practice won't validate SHA256-only signatures.
Windows 7 / Windows Server 2008 R2 without KB3033929 will be affected.
Windows 8 or later is OK.
From what I understood, SHA256 code signing support came in an update in Windows 7, but I don't know if this update is widely installed.
I don't know too.
KB3033929 is included automatic Windows Update, but sometimes I get a question about this from Windows7 user (who don't install KB3033929).
I have been using SHA1 signing for many years, but from 2016, Windows is forcing developers to use SHA256.
Windows Enforcement of Authenticode Code Signing and Timestamping
By using Windows 7 SDK signtool the functions to sign SHA-256 is "unknown commands", so this signtool is obsolete as a signtool and shouldn't be used any more.
To sign with SHA256 I downloaded the Windows 8.1 SDK to get signtool.exe which got the new functions(/fd and a few others). The BAT file and signtool works on Windows 8 and 10, so I know it works, but crashes on Windows 7 when it tries to timestamp the file.
I use a bat file to sign files, which looks like this(I edited the BAT file so it doesn't show variables, full paths, company name and passwords):
Path\signtool.exe sign /f "Path\Certificate.p12" /fd sha256 /p *password* /du "URL" /tr "timestampServer?td=sha256" /td sha256 /d "Product name" "Filename"
I guess, I don't have the proper SDK to support some of the functions, but I can't find any info on the internet on how to setup this on a Windows 7. I tried to install MS Visual C++ 2015 Redistributable (x64) on my machine without solving the problem.
Seems I'm no good at reading. I'm answering my own question as others could find it hard to find, just like I did.
Windows doesn't support the signtool.exe on Windows 7 any more, so that is why old/obsolete functions like SHA-1 signing is still working, but SHA-256 time stamping is a problem. I found this on MSDN:
Quote from MSDN: Note You can only use SignTool to sign your Windows
Store app packages on Windows 8 and later or Windows Server 2012 and
later. You can't use SignTool to sign app packages on down level
operating systems such as Windows 7 or Windows Server 2008 R2.
If you want to read the whole thing then look here:
How to sign an app package using SignTool
Using VS2013 and Windows 8.1
I have a .cer and .pfx file bought from Verisign. I am new to store apps. I have couple of questions
What is the difference between signing the package and code signing (done using the VS 2013 packaging tab of Package.appxmanifest) -
my understanding so far
(a) I guess this is similar to using signtool.exe tool right?
(b) both will install the public key(.cer) to certificate store(mmc) and sign the appx with private key(.pfx) so i would need to manually install .cer file in the live machines inorder to install my app?
(c) Code is signing is done in order to ensure the code has not been tampered with but do we need to do this for all main store app and other components used part of dfferent project (.dll)
Do we need both package and code signing inorder to publish store apps on client machine?
I can't use the same .pfx used for package signing for code signing because of some chaining information. Is this how it is supposed to used different .pfx for both is this a normal way?
For the regular Windows Store apps:
You don't need to sign windows store apps manually.
No. Windows Store will sign the package automatically.
Code signing is for Windows Classic apps or drivers and not for Windows Store apps.
For the sideloaded apps:
Windows store enterprise apps can be signed by any certification authority that is trusted on your PCs (where the app will be installed). It's better to sign with visual studio. There is documantation for an exact procedure.
If you will sign with Verisign certificate, you don't need to install anything except the app, because verisign root is already trusted in Windows. Visual studio signs only application package.
I have tried to run the NONPNP windows driver code. It installs and when I run the nonpnpapp.exe I get a driver signing error.
"windows requires a digitally signed driver"
I am running this on debug mode and release I am test signing it.
Why am I still getting this error?
I do know that x64 machines needs this, I am on windows7 x64.
So we need to do something else.
Visual studio output says that the sys file is successfully signed.
I trace the code. It copies the sys to system32/drivers after it is signed.
Windows device installation uses digital signatures to verify the integrity of driver packages and to verify the identity of the vendor (software publisher) who provides the driver packages. In addition, the kernel-mode code signing policy for 64-bit versions of Windows Vista and later versions of Windows specifies that a kernel-mode driver must be signed for the driver to load.+
Note Windows 10 for desktop editions (Home, Pro, Enterprise, and Education) and Windows Server 2016 kernel-mode drivers must be signed by the Windows Hardware Dev Center Dashboard, which requires an EV certificate. For details, see Driver Signing Changes in Windows 10. https://learn.microsoft.com/en-us/windows-hardware/drivers/install/driver-signing
Two options there;
1) allow test signing
2) disable driver signature enforcement
If you are using a dedicated test machine, I recommend the second option since I think it's more error proof.
I have purchased a certificate from http://www.ksoftware.net/ which I use to sign a .CAB file used for installation of our software on windows mobile 6.5 devices. However, even after signing the .CAB, when attempting to install the application on the device (via the CAB) the device alerts "Unknown publisher". These CAB files are downloaded from a webservice and are supposed to be installed automatically using wceload and its silent install options, but this fails since the CAB is not recognized as signed (once I have manually installed a particular CAB file, wceload will succeed for that CAB in the future).
Initially I only had the certificate set in the visual studio 2008 deployment properties, and the applications signing properties. I also tried using signtool.exe, and thereafter cabsigntool.exe to sign all the other files in the CAB too. None of these methods work. When checking the CAB's properties in Windows 7, the file does have a security certificate attached, but any attempt to install on the device gives the annoying "unknown publisher" popup box.
Is there anything I am missing? What could be causing the devices to still see the CAB files as unsigned? The signing does not seem to work with plain exe's either.
Please note I do know the security settings can be changed in order for the prompt not to come up, but I am interested in solving the security certificate problem.
I assume the root certificate of the sign is not know on the device:
Did you verify that the certs are WindowsMobile compatible?