I finally was able to set up the HCK test server and test system, and generate an HCKX. The test system we ran against is Windows 2012 R2.
I do NOT have access to my EV Certificate on the HCK controller system. I generated an unsigned .hckx file, and am trying to use the HLK Studio (which DOES have access to our EV Certificate) to sign it. Ideally, I’d like to end up with a driver that runs on Windows 2008 R2 (x64) through Windows 2022.
We’ve run the HLK tests against Windows 2019 successfully, and I am able to submit that to the Hardware Dev Center and get a signed driver that works on 2016, 2019, and 2022.
I was attempting to use the “merge” capabilities in the HLK Studio to bring in the .hckx file that we created on the HCK controller system. To do this, I created a new project and chose “Connect”, and loaded the previous .hlkx file. Then I chose “merge” and added the .hckx file. I cleared the Drivers Folder that was pointing to my user TEMP directory, and added a single Drivers folder that contains the driver that we tested on both systems (2012 R2 and 2019). The Driver Properties lists both “Windows Server v10.0 17763” and “Windows Server v6.3” - I highlighted both of those, and added the English locale. Then I added a Symbols folder.
I signed the resulting .hlkx file with our EV Certificate and uploaded it for signing at the HW Dev Center.
The resulting download contains a signed copy of the driver, but the Microsoft signature is SHA256 (which I don’t believe will work on 2012 R2). I tried installing it on a 2012 R2 system - won’t boot.
Any idea what I need to do differently to get this to work? Thanks!
Ernie Coskrey
Are you saying that the certificate used to sign the original driver that we tested with may not be what we need? That certificate is a cross-signing certificate, and it appears to be sha-1 in the “Properties / Digital Signatures” for the driver file. Details show that it is sha384.
We’ve had a number of releases since 2019 using this cross-signing certificate, including one earlier in 2021. We didn’t have any issues with 2008 R2, 2012, 2012 R2 booting with that driver.
It is entirely unclear (clearly unclear?) whether it is now possible to construct a single package that works from WS08R2 through WS22. However, the SHA256 thing only applies to Windows 7 original, which is the kernel in WS08. Everybody from WS08R2 onward should be able to handle it. WS12R2 (which is Windows 8.1) should have no trouble with SHA256.
Here’s a recap of what I’ve tried - maybe there’s something obvious (to someone) that I’m missing.
I’ve signed my driver with a valid Sectigo cross-signing certificate, with both sha-1 and sha-2, and both signatures timestamped.
I tested this driver under HCK on a Windows 2012 R2 test system, and everything passed. In HCK Studio, I generated an unsigned .hckx file (because I don’t have access to the EV certificate on the HCK controller). I copied this hckx to my HLK controller system, and started HLK Studio there. I created a new project, and connected to the hckx. From there I created a package (hklx), adding my driver and symbols folders, and signing the package with the EV Certificate.
Then I logged into the Hardware Dev Center and chose Submit New Hardware. I uploaded the signed hklx. I didn’t choose any of the “Requested Signatures” check boxes, and saw that Windows Server 2012 R2 is displayed in the Certification section. I filled in the rest of the form and let the submission proceed.
When the process finished, I downloaded my signed files. I extracted the driver from the zip archive and saw that it now has 3 signatures (2 from my cross-signing certificate, plus one from Microsoft). I installed this on a Windows 2012 R2 system and rebooted and the boot failed to load my driver - I had to go in and repair the system by replacing my driver with an older released version.
I’ve tried the same thing with choosing “Windows 2008 R2 x64” checkbox in the “Requested Signatures” section. But that doesn’t result in a working driver either.
I don’t know… sounds like you’ve basically followed the procedure, and done exactly what we do… with the exception of checking the various “Requested Signatures” check boxes. We basically check EVERY BOX that applies (all the x64 for a 64-bit AMD64 architecture submission, for example).
When you say you “installed this” on S12R2… do you mean you copied the file to \windows\system32\drivers… or that you did an actual installation activity (that worked successfully)??
Peter
Yes “installed” means I copied the driver file to C:\windows\system32\drivers and rebooted.
Thanks for confirming that I’m not doing something totally wrong. I’ll keep plugging away. The latest thing we’re trying is to generate a .cat file for the driver; we previously didn’t have a .cat file in the driver folder (just .inf and .sys).
And MSFT signed that driver package? Without a cat file??
That confuses me…
Peter
The Microsoft signing process does not care whether you provide a CAT file or not. They throw yours out and create a new one, always.
The PnP installation process certainly cares, but WHQL and attestation signing don’t require it.
Here’s the solution that we came up with. And also another question for the list.
We were able to complete HLK testing, on a Windows 2019 system with testsigning enabled, using our driver that has a sha-1 signature using our code signing certificate. The tests all passed.
Before creating the hlkx submission package, we removed the signature from the driver in the Driver Folder using “signtool remove /s <driver.sys>”. Then we created the package, submitted it to the hardware dev center, and got back a signed driver with a single Microsoft sha-256 signature. This driver works on all the platforms that we support - Windows 2008 R2 through Windows 2022.
My question is - is there any downside to using this driver, signed only by Microsoft? Or do we need to append a sha-1 signature using our code signing certificate? Or even append a sha-1 and sha-256 signature? As long as the Microsoft signature is first in the list, the driver appears to work fine on all the platforms.
For Win 7 system, we just don’t sign the driver(s) during submission. We get the signed driver back from Microsoft, and THEN we sign it with our Cert.
The advantage to having YOUR signature on the executable is that it ensures (your customers) that the driver authentically originated from YOU.
Peter