P
Pablo DP
Guest
Hi,
We have Cross-Certificate signed x64 (and x86) kernel device driver for our PCI-express telephone boards, using Digicert Certificates. So the drivers are signed locally and don't go thru the MSFT Dev Portal.
We've been doing this for years, and even for Windows 2016.
We recently encountered a customer constantly getting failures loading the Device driver for our boards. Looking into the Event Viewer, etc noticed the following:
0x34 (CM_PROB_UNSIGNED_DRIVER)
and:
The digital signature for this file couldn’t be verified, Error 0xc0000428
We noticed that the peculiar thing different than most other customers, or what we had tried in our lab, is that the customer had enabled Secure Boot. We asked the customer to disable Secure and that solved their problem.
That rang a bell based on the Windows 10 MSFT Policy as per:
Driver Signing Policy - Windows drivers
"Starting with Windows 10, version 1607, Windows will not load any new kernel-mode drivers which are not signed by the Dev Portal. "
AAMoF there are exceptions, and one is: "Secure Boot is off in the BIOS."
We indeed have Dev-Portal (Attestation) Signed device drivers for Windows 10 to meet the demands of this policy; we do have an EV Certificate and submit the drivers to the MSFT Dev Portal. The device driver is the same (WDF model) for the two OS, obviously, what changes is the Digital signature, and due to this above policy we *only* install the Dev-Portal Attestation-Signed drivers when we detect a Windows 10 installation.
I have not seen anything official, that I can tell, from MSFT, regarding the same policy applying to Windows Server 2016. However it would make sense from the point of view the Windows kernel is shared for Windows 10 and Windows 2016.
So, then we asked them to configure Secure Boot back, and we sent them the Dev-Portal Attestation Signed drivers for Windows 10, remove the original one, and install this one instead.
This *also* worked.
So my educated guess is that MSFT is enforcing the same Dev-Portal Digitally signed drivers policy as indicated above, on Windows Server 2016.
I'm trying to find confirmation of that and official documentation.
If that is the case I need to know if there is a separate Attestation-Signed Dev Portal submission procedure for Windows Server 2016 (and presumably for Windows Server 2019).
Many thanks!
Continue reading...
We have Cross-Certificate signed x64 (and x86) kernel device driver for our PCI-express telephone boards, using Digicert Certificates. So the drivers are signed locally and don't go thru the MSFT Dev Portal.
We've been doing this for years, and even for Windows 2016.
We recently encountered a customer constantly getting failures loading the Device driver for our boards. Looking into the Event Viewer, etc noticed the following:
0x34 (CM_PROB_UNSIGNED_DRIVER)
and:
The digital signature for this file couldn’t be verified, Error 0xc0000428
We noticed that the peculiar thing different than most other customers, or what we had tried in our lab, is that the customer had enabled Secure Boot. We asked the customer to disable Secure and that solved their problem.
That rang a bell based on the Windows 10 MSFT Policy as per:
Driver Signing Policy - Windows drivers
"Starting with Windows 10, version 1607, Windows will not load any new kernel-mode drivers which are not signed by the Dev Portal. "
AAMoF there are exceptions, and one is: "Secure Boot is off in the BIOS."
We indeed have Dev-Portal (Attestation) Signed device drivers for Windows 10 to meet the demands of this policy; we do have an EV Certificate and submit the drivers to the MSFT Dev Portal. The device driver is the same (WDF model) for the two OS, obviously, what changes is the Digital signature, and due to this above policy we *only* install the Dev-Portal Attestation-Signed drivers when we detect a Windows 10 installation.
I have not seen anything official, that I can tell, from MSFT, regarding the same policy applying to Windows Server 2016. However it would make sense from the point of view the Windows kernel is shared for Windows 10 and Windows 2016.
So, then we asked them to configure Secure Boot back, and we sent them the Dev-Portal Attestation Signed drivers for Windows 10, remove the original one, and install this one instead.
This *also* worked.
So my educated guess is that MSFT is enforcing the same Dev-Portal Digitally signed drivers policy as indicated above, on Windows Server 2016.
I'm trying to find confirmation of that and official documentation.
If that is the case I need to know if there is a separate Attestation-Signed Dev Portal submission procedure for Windows Server 2016 (and presumably for Windows Server 2019).
Many thanks!
Continue reading...