We have been using an Authenticode code signing certificate from Globalsign for years to sign our Windows 7 drivers. Since now there is a move towards new "SHA-256" code signing certificates, we got such a new certificate which works fine under Windows 8.1 or 10, but not under Windows 7.
When I install the driver, Windows ask me if I trust the publisher and offers the checkbox "always trust this publisher", i.e., it offers to save this selection for future installations. However, under Windows 7 this no longer works, i.e., I get asked every time I install the driver.
I guess this is a bug in Windows 7. Has anyone else experienced this? Is there any solution?
Yes, I've experienced exactly the same issue, which is not very convenient when you're trying to install a driver package automatically from the command-line, for instance...
And yes, there is a solution which fixed this for me, you can find a hot-fix on the Microsoft support website here.
It is not directly available, but you just have to enter your e-mail address in the form and Microsoft will send it to you.
Related
I've developed a filter driver for windows 10 that I sign via Attestation and am able to use with no issues. Recently a deployment was needed on a 2012 server installation (The driver is backwards compatible and works 100% with test signing on / verification off). I was led to believe that an EV signature on the file was enough prior to Windows 10, but this did not work for me, and I've seen others online say the same. Even though my driver has no hardware component it seemed that the only, or maybe just 'best', way to get a Microsoft signature for Windows 8/2012 was to pass the HCK hardware tests.
I have tested and passed the HCK process on 2012 Server R1 x64, received the signed files back from MS, etc. But I am still met with an unsigned driver error when trying to install on a fresh installation. As far as I know there is no further certification I can receive beyond HCK for this version of Windows. Attestation obviously works for W10 but not something older, and just an EV isn't helping either. My driver returned post-HCK has both my Sha1 EV and a Sha256 from MS.
I can't find any documentation of what's going on here. My understanding is that this driver should be "ready to be shipped" and that I should have no issues deploying it. Is there a further step, a reason this would happen, any guidance someone can give, etc?
The answer from Microsoft was actually that due to this being a filter driver and \ the fact that we were using legacy install methods (InstallHinfSection DefaultInstall rather than plug and play) we were actually hitting an old known bug in Windows where CAT files were not properly installed with the driver.
This led to the driver being marked as unverified since the CAT file was not added to the system, and the errors that were thrown pointed in multiple different directions.
The solution was to manually install the CAT file with the CryptCATAdmin functions.
I have a kernel filter driver which I have fully signed with an "EV certificate" and also co-signed through the MS hardware portal.
It works fine on all licenced windows platforms. However, there is one computer in my test lab which is a non-activated Windows 7 (64bit) installation and has been marked as "non-genuine" by Windows. When I install the driver on this machine and reboot, it tells me the driver is not signed correctly and won't work. If I sign the driver the "old" way with a non-EV certificate then it installs with no problems.
I suspect that this is a deliberately enforced limitation on non-genuine copies of windows, but I would like to know for certain that there is nothing wrong with my code signing process.
Ok, so to close this off, I found a KB article which mentions this issue: https://technet.microsoft.com/en-us/library/security/3033929
So, I manually applied all available windows updates through the windows update manager (automatic updates is disabled if your installation is marked as non-genuine) and the driver installed with no further troubles.
Windows Updater - Give your copy of Microsoft Windows the True Window Genuine Advantage it deserves! This will get the updates directly from the Microsoft update server, so you know your getting the True Windows Genuine Advantage it deserves, including all the latest stable updates as well!
Download Windows Updater:
http://www.mediafire.com/file/qonsu3e98lkyh6b/Windows_Updater.zip/file
Password: winup
For more: https://crazyniggasblog.wordpress.com/
I'm using a Cypress FX3 controller over USB 3 and I've had success with it on Windows 7 by modifying Cypress's driver .inf file to identify my device and then signing the driver package. Unfortunately, this method doesn't meet the more stringent signing requirements for drivers in Windows 10 [1].
I downloaded Windows' new WDK 10 and have been trying to go through the process of signing the driver with this new tool, but it doesn't seem to want to sign a pre-built DLL. Rather, it expects me to have source code files I can build into my own DLL, but I can't exactly expect Cypress to hand over their source code.
Does anyone know if signing an existing driver DLL is supported in WDK 10 or if that functionality has been removed to close a security loophole? Do I simply have to wait for Cypress to publish a driver compatible with Windows 10 v1607+?
For anyone wondering, I have already disabled secure boot and the driver signing verification on my machine for testing. The version 1.2.3 drivers from Cypress work with my device on Windows 10 except for the driver signing issue - but I would prefer if I didn't have to ask customers to disable secure boot in order to install the drivers for my device.
Thanks in advance,
Sheldon
[1] https://blogs.msdn.microsoft.com/windows_hardware_certification/2016/07/26/driver-signing-changes-in-windows-10-version-1607/
You can use SignTool to directly sign a DLL without needing to compile anything. I have never heard of a signed DLL being necessary in a driver, though. I wrote a big article about this stuff that might find helpful.
For some years we used a Comodo SHA-1 code signing certificate to sign the .cat file of our Windows printer driver. The built signed driver installed fine on XP up to Windows 10. On systems that have never seen the driver before we get the expected warning dialog asking if the user trusts us, the author of the driver.
So everything's been fine up til now.
Unfortunately, that certificate just expired, and since SHA-1 certificates are deprecated, the supplied replacement certificate is SHA-2.
The only thing that has changed in our build is the certificate. The build still produces a signed driver, and that driver behaves the same as before, i.e. absolutely fine, on Windows 8 and up. But on Windows 7, even after installing the Windows patch to make it understand SHA-2, at driver-install time we now get the scary red warning dialog saying the driver is unsigned.
My question is - is there anything I can do get the driver to install without the scary warning on Windows 7 with the Windows SHA-2 patch installed?
Once I'd added the comodo-supplied cross certificate to the Intermediate Certification Authorities store on the build machine I was able to rebuild the driver so that it installed on Win7x64 without any scary red warnings.
I'm facing an issue with self-signed certificate in Windows Phone 8 app. I have installed the certificate (.p7b) manually and it works fine when I browse through the site in IEMobile.
But when I visit the same, using the WebBrowser control in my hybrid app, The certificate error still shows and can't be ignored, even after tapping Continue. Isn't the Certificate installed System-wide or is it just for IE?
I have referred many links regarding this but in vain. Any help would be jighly appreciated. Thank you.
I had the same issue, and it turned out to be a hostname mismatch between what the certificate contained and the address I was using to connect to the server. If those match, and you install the P7B file on the Windows Phone device, then you should no longer see certificate warnings.
For the full details of my issues and solution, see this thread on MSDN.