Vista TESTSIGNING mode effect on INF portion of install?

NTDEV
1

Anyone know how complete an experience am I supposed to be expecting
in response to setting up a test signing scenario, such as is
described in Kernel-Mode Code Signing (KMCS) Walkthrough (06JUL2006)
(http://www.microsoft.com/whdc/winlogo/drvsign/kmcs_walkthrough.mspx).

I’m creating software-only drivers as components of a NetClient-class
driver installed via INetCfg.

When manually registering an x64 driver as a service Windows will
start (i.e. not using an INF to install the driver; just create a
properly-formatted service entry), having the driver test-signed and
TESTSIGNING mode enabled via BCDEDIT appears to work as expected, and
Windows does not fail loading the driver due to signature verification
at boot time.

Now we’re finally starting to use the actual .INF-based install for
the driver, and in the test-signing scenario we still see the “Windows
can’t verify the publisher of this driver software” approval dialog
when we’re using INetCfg to request that our NetClient-class driver be
installed.

The only question is whether this prompt was, or was not, supposed to
still be seen when installing a driver via an .INF in the case where
TESTSIGNING mode is enabled.

Approving the dialog allows install to proceed, but that’s not unique
to TESTSIGNING mode. (Could already do that, even unsigned.)
TESTSIGNING mode clearly is letting the driver actually load in
kernel-mode, but what effect if any should have occurred during the
processing of the INF.

The KMCS walkthrough document was specific on what dialogs I expected
to see in a release-signed environment, but simply says things like
“click next in the next two pages” when describing the test-signed
experience, so I don’t know if what I’m seeing is unexpected or not.

Assume the KMCS walkthrough document was followed for setting up the
test-signing scenario; i.e. the self-generated test certificate has
been installed under Trusted Publisher, the certificate for Root
Agency that issued the self-generated certificate has been installed
under Trusted Root Certification Authorities, SIGNTOOL.EXE VERIFY /PA
confirms that the .INF and catalog have been properly signed and
verify successfully according to the Authenticode policy (on the same
machine that I subsequently attempt to install on), etc.

Alan Adams

2

“Alan Adams [1492637]” wrote:

> Now we’re trying to use an actual .INF-based install for the driver,
> and in the test-signing scenario we still see the “Windows can’t
> verify the publisher of this driver software” approval dialog when
> we’re using INetCfg to request that our NetClient-class driver be
> installed.
>
> The only question is whether this prompt was, or was not, supposed to
> still be seen when installing a driver via an .INF in the case where
> TESTSIGNING mode is enabled.

Gosh dang it, Peter told us in no uncertain terms “follow how the
walkthrough does it EXACTLY and don’t get creative”. Yet here I am,
bein’ goofy.

The fault in this case seems to be that instead of installing the
“Root Agency” certificate into the Trusted Root Certification
Authorities using the method prescribed in the walkthrough
(“certmgr.exe /add /c /s /r localMachine CA /n “Root Agency” /s /r
localMachine root”), I simply ran CERTMGR.MSC and dragged “Root
Agency” from “Intermediate Certification Authorities” to “Trusted Root
Certification Authorities”.

The outcome looks the same visually in Certificate Manager (not that
this means anything, except to my fellow idiots). But I would like to
explicitly point out (and not as a defense to my not following
directions) that SIGNTOOL.EXE VERIFY /PA does_successfully_verify
the .INF and .CAT in this scenario.

(i.e. I have test-signed my .CAT, installed the test signature on the
test machine by right-clicking the .CER file and letting the
Certificate Manager wizard install it to “Trusted Publishers”,
drag-n-dropped “Root Agency” in Certificate Manager as described
previously, and then I run “SIGNTOOL.EXE VERIFY /PA /V /C my.cat
my.inf” and it shows the chain without warnings and declares
“Successfully verified: my.inf”.)

Note also that right-clicking the .CAT and looking at the “Digital
Signatures” tab and displaying the details of my test signature
declared “Digital signature is OK”, apparently confirming that “Root
Agency” was known as a certification authority.

But the setupapi.dev.log still declared “a certificate chain was
processed, but terminated in a root certificate which is not trusted
by the trust provider” when I tried to trigger installation via
INetCfg, as though “Root Agency” was in fact not known.

Once I started clean again and did it exactly how the KMCS walkthrough
said to do it (cermgr.exe command line install of both my test
certificate and “Root Agency”), my same test-signed .CAT and .INF
package appear to no longer be triggering the “Windows can’t verify
the publisher of this driver software” approval dialog.

My best guess at the moment is that my drag-n-drop approach did
something that was valid for HKEY_CURRENT_USER only, and as such
seemed valid for SIGNTOOL.EXE and the “Digital Signatures” tab in
Windows Explorer. But was not valid in the context of INetCfg
invoking SETUPAPI.

I will be available from 6:00pm - 8:00pm CDT today for public
flogging.

Alan Adams

3

That actually got me to laugh out loud this morning, Alan, thanks…

Note to all: I hear that the KM Walkthrough doc has been recently updated to reflect how test signing mode works on Vista and (I believe) to include references to the use of INF2CAT (which is preferred by just about everyone to SIGNABILITY).

Peter
OSR