The drivers saga continues…
Update 2015-01-28: This article is for Windows 7 only. To learn sign drivers for Windows 8.1 and Windows Server 2012 R2, with real certificates, check this article:
Deploying Windows Server 2012 R2 to Intel NUC devices using MDT 2013
https://deploymentresearch.com/Research/tabid/62/EntryId/222/Deploying-Windows-Server-2012-R2-to-Intel-NUC-devices-using-MDT-2013.aspx
Background
For a driver to be ranked correctly by the windows 7 setup it should be signed, and for Windows 7 x64 deployments it really needs to be signed. However, sometimes vendors don't provide signed drivers, or you need to modify a driver for a specific device, and when you do, you break the signing. For Windows 7, the solution is to sign the driver yourself.
In this example you sign an unsigned driver for Windows 7 named b57nd60a.inf (yes, it's the Broadcom NetXtreme Desktop driver) for the fictive company ViaMonstra. The scenario is that you have modified the b57nd60a.inf file so that the signing is now broken.
This means if you for example try to add the driver to the Windows 7 driver store using pnputil -a b57nd60a.inf you will be met by the following.
Signing drivers – Overview
- Get the tools
- Create the certificate and private key
- Create the catalog file
- Sign and timestamp the driver
- Install the certificate
Signing drivers – Detailed steps
Again, in this example you sign an unsigned driver named b57nd60a.inf for the fictive company ViaMonstra. Remember that the scenario is that you have modified the b57nd60a.inf file so that the signing is now broken.
Step 1 – Get the tools
Go to https://microsoft.com/downloads, download and then install the Windows SDK for Windows 7
Go to https://microsoft.com/downloads, download and then install the Windows Driver Kit 7.1.0
Step 2 – Create the certificate and private key
Create a folder named C:ViaMonstraDriversCert
Start the command prompt and type the following commands, press Enter after each command.
cd /d "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin"
makecert -r -sv C:V\iaMonstra\Drivers\Cert\ViaMonstra\Drivers.pvk -n CN="ViaMonstra" C:\ViaMonstra\Drivers\Cert\ViaMonstra\Drivers.cer
Assign a password of P@ssw0rd
cert2spc C:ViaMonstraDriversCertViaMonstraDrivers.cer C:ViaMonstraDriversCertViaMonstraDrivers.spc
pvk2pfx -pvk C:\ViaMonstra\Drivers\Cert\ViaMonstra\Drivers.pvk -pi P@ssw0rd -spc C:\ViaMonstra\Drivers\Cer\tViaMonstra\Drivers.spc -pfx C:\ViaMonstra\Drivers\Cert\ViaMonstra\Drivers.pfx -po P@ssw0rd
Step 3 – Create the catalog file
Create the C:\ViaMonstra\Driver\sCer\tBroadcom folder and copy the b57nd60a.inf and b57nd60a.sys file to it.
Start the command prompt and type the following commands, press Enter after each command.
cd /d "C:\WinDDK\7600.16385.1\bin\selfsign"
inf2cat.exe /driver:"C:V\iaMonstra\Drivers\Cert\Broadcom" /os:7_X64 /verbose
Step 4 – Sign and timestamp the driver
Create the C:\ViaMonstra\Drivers\Cert\Broadcom folder and copy the b57nd60a.inf file to it.
Start the command prompt and type the following commands, press Enter after each command.
cd /d "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin"
signtool sign /f C:\ViaMonstra\Drivers\Cert\ViaMonstra\Drivers.pfx /p P@ssw0rd /t http://timestamp.verisign.com/scripts/timstamp.dll /v C:\ViaMonstra\Drivers\Cert\Broadcom\b57nd60a.cat
Step 5 – Install the certificate
To trust the certificate on a single test computer (current signing certificate is private, and not yet trusted by the operating system) start the command prompt and type the following commands, press Enter after each command.
certmgr.exe -add C:\ViaMonstra\Drivers\Cert\ViaMonstra\Drivers.cer -s -r localMachine ROOT
certmgr.exe -add C:\ViaMonstra\Drivers\Cert\ViaMonstra\Drivers.cer -s -r localMachine TRUSTEDPUBLISHER
Note #1: You can also use certutil to install the certificate
Note#2: You also need to configure Windows to allow drivers certificates that are not cross-signed by Microsoft by running the following command in an elevated command prompt and then reboot: bcdedit /set testsigning on
Now when you try running pnputil -a b57nd60a.inf you will be met by the following:
References:
MSDN docs on driver ranking:
How Windows Ranks Drivers (Windows Vista and Later)
http://msdn.microsoft.com/en-us/library/windows/hardware/ff546225%28v=vs.85%29.aspx
/ Johan
Many thanks for your reply, a new controller it is then.
hgreenwood, Windows 8.1 and Windows Server 2012 R2 have slightly different requirement for drivers. I'll see if I can update the post to reflect that.
/ Johan
Jeeves, Not really, this post is not for using the driver as part of deployment, just to provide a way of adding unsigned drivers to a running system, primarily for testing….
According to Adaptec, they don't support any x64 drivers for the 2940 u/uw, only x86 drivers. More info here: http://www.adaptec.com/en-us/support/scsi/2940/aha-2940uw
My tip is buy a new controller.
/ Johan
Please can you tell me if this will resolve my problem?
I am trying to install W7 x64, my system only has SCSI drives via an Adaptec 2940u/uw controller card. There is no W7 x64 support for this card, however there was x64 support for Vista. I have the Vista drivers but of course W7 says "driver not signed". Can I use your info to sign this driver for W7.
Many Thanks
Please can you tell me if this will resolve my problem?
I am trying to install W7 x64, my system only has SCSI drives via an Adaptec 2940u/uw controller card. There is no W7 x64 support for this card, however there was x64 support for Vista. I have the Vista drivers but of course W7 says "driver not signed". Can I use your info to sign this driver for W7.
Many Thanks
Great post . How do you do this for windows 2012 r2 ?
Sorry, haven't seen that… If you still need help, please ping me offline (see contact info in the About link).
/ Johan
Just tried to start following your instructions. Interestingly, the download from Microsoft for Windows SDK gives me a message that it cannot execute because a .cab file in the executable is unsigned. I found that a bit ironic.
If the certificate you used to sign the driver is trusted by the machine you should be good.
/ Johan
hi! successfully signed driver based on instructions above but i still get the notice on device manager:
"Windows cannot verify the digital signature for the drivers required for this device. 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. (Code 52)"
i used godaddy code signing cert to sign driver. was wondering how to get rid of this message?
thanks
To clarify. We didnt want to inject the drivers in the images as we use quite a few different images. But from what I gather there might be a good way to do it headache free so I'll look into it!
Thanks for your reply! We were actually happy with WDS/WSIM combination but this 'x64 drivers have to be signed' is just silly. We're the friggin sys administrators, we know it's not signed we changed them ourselves. Come on Microsoft! Provide an 'ignore' button…
Anyways, thanks again for your reply, I'll look into MDT and see if that offers us any advantages!
I never ever use WDS as is for deployment so I don't know. You should integrate WDS with MDT to get a deployment solutions that provides with solid driver injection routines. The driver (and OS deployment) handling in WDS is nothing but a joke. The only thing WDS is good at is provide a way to network boot the MDT boot image, and to provide multicast (optional) for the OS images in MDT.
/ Johan
Hi We've been trying to use your method to get WDS to add our Intel HD Graphics drivers into the Console under the drivers branch.We've used the command line to add the drivers and verified it won't add the drivers because the drivers aren't signed. Now, we've followed the procedure and effectively, we get the same end result as you do.BUT, WDS still says the driver is unsigned when we try to add it. I have to admit I'm not entirely understanding the proces. Could you provide any help as to what steps might be different when you try to… Read more »
Hi Johan,
This is what was puzzling me, because this is complete procedure for driver signing, and I tried to install certificate over and over, it says every time successfully installed.following all of the five steps give me exactly same results as mentioned above. Even in group policy, everything is fine. Reboot , uninstall, reinstall etc.. all the possible methods attempted. I have windows 7 X64, enterprise version, and its corporate (company)laptop,may have some hidden scripts running.
Thanks for the feedback, I have made a note in the post.
/ Johan
After following all the procedure successfully, still I couldn't install my driver on X64. Finally I found elsewhere solution, Which should be added to above.
Open Cmd in elevated mode(Run as administrator)
Type bcdedit.exe -set TESTSIGNING ON
Reboot
Now Install Driver.
Printer drivers is another area there this could be very usefull.
Color/Black and White, duplex settings and so on correctly set in accordance to your policies…..
You are absolutely correct, pushing a cert via GPO won't help if you inject drivers during deployment… only for running pnputil or dpinst to push out drivers as an "application". For adding drivers during deployment the certificate needs to go in the reference image
/ Johan
I have been wanting to re-sign drivers for a long time, but never wanted to invest the time to figure out how to do it, thanks.This is especially useful with NIC drivers where you might want to adjust some default settings different from the manufacturer (like powersave/sleeping.) I am thinking of signing the certs with one issued from the domain CA – that way all domain clients will automatically trust the drivers without further action. You also mention deploying these certs via a GPO. In both methods though, this gets the certs to the client too late during OS deployment,… Read more »