I have a kmdf upper filter driver, based on the toaster sample driver, for which I generate a test signing certificate and catalog file using the options in Visual Studio 2017 for “Driver Signing” and “Inf2cat” categories on the project property page. The driver builds successfully for a amd64 platform running Windows 10, version 1803 with messages stating that signing was successful. A project.cer, toaster.cat, filter.inf and filter.sys file are produced. I have imported the project.cer file into “Trusted Root Certification Authority” and “Trusted Publishers” folders using MMC.exe certificates snap-in. Upon opening the resulting entries and reviewing the associated details it looks like the certificates are OK. I can install the driver with the test machine booted so as to disable the signing enforcement and the resulting driver details, as viewed in Device Manager, show the driver to be digitally signed with a signature that matches what is shown in the MMC window for the associated certificate. I have run sigverif.exe with the driver installed and it shows its signature as having been accepted. However, when I reboot the machine without disabling signature enforcement I get a Code 52 error in Device Manager stating that the certificate is not trusted. I have researched this problem until my head is about to explode and have now come to believe that Microsoft’s current Driver Signing Policy as of Window 10, version 1607, precludes any certificates for kernel-mode drivers (including test certificates) not issued by their Dev Portal from being trusted. If this is correct than Visual Studio 2017 is misleading, as is most of the on-line documentation, that makes one think that test signing can be done within VS or by using the development tools of the SDK and WDK. Have I come to the correct conclusion and do I have to submit a request to the Dev Portal for a test certificate?
On Feb 16, 2019, at 10:29 AM, Stroker347 wrote:
>
> If this is correct than Visual Studio 2017 is misleading, as is most of the on-line documentation, that makes one think that test signing can be done within VS or by using the development tools of the SDK and WDK. Have I come to the correct conclusion and do I have to submit a request to the Dev Portal for a test certificate?
You can do test signing using your own certificate, as long as you either disable signature verification or attach a kernel debugger. Otherwise, you have to submit your driver for attestation signing through the hardware dashboard.
I don’t think Microsoft issues test certificates any more, but I may have missed a memo.
—
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
So there is no point in test signing, except maybe to learn the steps required to sign, if one has to disable signature enforcement anyway. As a hobbyist who develops drivers only for myself, disabling enforcement is viable but very time consuming (at least on the old laptop that I’m using as my test machine) since it often involves back-to-back reboots. One boot-up when the machine is turned on or restarted and another after getting to the disable boot option. Is there any practical means for a hobbyist to get a valid certificate?
I have not had any issues in setting test signing on the target and installing the test certs from VS. My drivers do load without using the debugger or F8 boot.
Bill Wandel
Bill,
Are you targeting a Win 10, Version 1607 or later amd64 platform and installing a kernel mode driver? What version of VS are you using and are you using the default settings for driver signing and catalog generation (Inf2Cat) or have you manually set them up? Are you using the VS default WDKTestCert and SHA1 hash for signing? Do you timestamp your files and if so which files?
I have been targeting the latest WIN10 including RS6. My drivers are software drivers, no hardware. My VS version is 15.9.3. The key is to have test signing enabled on the target.
Bill Wandel
Thanks Bill, I’ll have to try “bcdedit -set TESTSIGNING ON” but unfortunately it requires disabling Secure Boot (as does “bcdedit /debug on” for using a kernel mode debugger to disable signing enforcement). I’m reluctant to disable Secure Boot for extended periods after reading a Microsoft document that stated that changes to the system, such as software installations, with it disabled could result in not being able to re-enable it without restoring the OS to its original state. I suppose creating a restore point prior to disabling Secure Boot would be adequate protection. But in the end I think disabling enforcement via the boot option may be less trouble with no similar risk.
I didn’t realize you were testing on a secure boot system. For this test signing will not work and you need to submit the driver to the Microsoft portal. The company that I am working for doesn’t test with secure boot during development. Signed with the company cert plus the Microsoft cross cert is all that is needed. Secure boot testing is done before the release.
Bill Wandel
Bill,
Turning TESTSIGNING ON does indeed do the trick. So now I know that the testing signing process for my driver worked correctly. This option is preferable to disabling enforcement by attaching a kernel mode debugger since its simpler, will persist with reboots, still enforces driver signing and has the same drawback regarding disabling Secure Boot (SB). I was hoping that I could re-enable SB once I had TESTSIGNING ON but no such luck, re-enabling SB turns off TESTSIGNING. If I can convince myself that periodically disabling SB is no more risky than completely disabling signing enforcement with the boot option this would be the preferable method.
Thanks again for clueing me into this feature.
On Feb 17, 2019, at 6:24 AM, Stroker347 wrote:
>
> So there is no point in test signing, except maybe to learn the steps required to sign, if one has to disable signature enforcement anyway. As a hobbyist who develops drivers only for myself, disabling enforcement is viable but very time consuming (at least on the old laptop that I’m using as my test machine) since it often involves back-to-back reboots. One boot-up when the machine is turned on or restarted and another after getting to the disable boot option. Is there any practical means for a hobbyist to get a valid certificate?
Well, yes; if you are working on your OWN computer, you can disable “Secure Boot” in the BIOS. Once you do that, the signature behavior is identical to pre-Win 10 systems. You can sign with your own certificate using Microsoft’s cross-certificate. It only gets icky when you want to distribute your driver to systems where you do not control the BIOS.
—
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.