Jump-start your project by learning from devs who
write Windows drivers and file systems every day.
Take an OSR seminar!

OSR is Hiring! Click here to find out more.

Upcoming OSR Seminars:
Kernel Debugging & Crash Analysis for Windows Lab, Santa Clara, CA 9-13 September, 2013
Upcoming OSR Seminars:
Windows Internals & Software Drivers Lab, Santa Clara, CA 16-20 September, 2013
Writing WDF Drivers for Windows Lab, Boston/Waltham, MA 7-11 October, 2013
Developing File Systems for Windows, Seattle, WA 5-8 November, 2013

Go Back   OSR Online Lists > ntdev
link Driver Signing for Vista 32
Welcome, Guest
You must login to post to this list
  Message 1 of 24  
03 Nov 10 12:20
Bob Sisson
xxxxxx@ncr.com
Join Date: 03 Nov 2010
Posts To This List: 4
Driver Signing for Vista 32
I'm a newbie with driver signing. We have a an existing driver that needs to be signed to load silently on Vista32. I've performed the following task, but always get a driver not signed error. 1) created a self signed test cert, loaded the public key version on the target machine, loaded both on my dev machine 2) created a cat file using inf2cat (from the latest win ddk) 3) signed the cat file using the test cert and signtool 4) verified the signature using sign tool 5) viewed the cat file and all looks ok 6) configured the vista machine to use test certs (test shows in all 4 corners) 7) tried loading the driver using devcon, pnputil and snetcfg -- always get the security error repeated the process but signed the .sys file, also no avail. our normal install is: snetcfg.exe -v -l ourinf.inf -m ourinf_m.inf -c s -i nt_ourinf however, I get the error if I use devcon to install ourinf.inf directly Someone told us we need to go through whql to resolve this, but the documentation seems to indicate otherwise. I'm guessing that there is something wrong with the .inf file? Thanks for all your help, Bob Sisson Robert Sisson Product Development Technical Specialist NCR Corporation xxxxx@ncr.com<mailto:xxxxx@ncr.com> | www.ncr.com<http://www.ncr.com/> --
  Message 2 of 24  
03 Nov 10 12:27
Don Burn
xxxxxx@acm.org
Join Date:
Posts To This List: 3179
Re: Driver Signing for Vista 32
32 bit drivers do not have to be signed, but to load silently you need a WHQL signature not a selfsign. See http://www.microsoft.com/whdc/winlogo/default.mspx for details. Don Burn (MVP, Windows DKD) Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr "Sisson, Robert" <xxxxx@ncr.com> wrote in message news:152237@ntdev: > I'm a newbie with driver signing. We have a an existing driver that needs to be signed to load silently on Vista32. I've performed the following task, but always get a driver not signed error. > > 1) created a self signed test cert, loaded the public key version on the target machine, loaded both on my dev machine > 2) created a cat file using inf2cat (from the latest win ddk) > 3) signed the cat file using the test cert and signtool > 4) verified the signature using sign tool > 5) viewed the cat file and all looks ok > 6) configured the vista machine to use test certs (test shows in all 4 corners) > 7) tried loading the driver using devcon, pnputil and snetcfg -- always get the security error > <...excess quoted lines suppressed...>
  Message 3 of 24  
03 Nov 10 12:41
Bob Kjelgaard
xxxxxx@microsoft.com
Join Date: 16 Apr 2008
Posts To This List: 131
RE: Driver Signing for Vista 32
1) Did you put the certificate in the local machine's TrustedPublisher and Root stores (and it must be localmachine, not the logged-in user's store it will otherwise default to, as parts of the install run in a system and not a user context)? That may be what you meant by "loaded it" but that's not at all clear to me. 2) Signing errors are always accompanied by some fairly comprehensive logging information as to why a driver was deemed unsigned (e.g. file not in the catalog, file altered from what was cataloged, etc), in %windir%\inf\setupapi.dev.log. What does it say Is wrong with your signature? ---------- I'm a newbie with driver signing. We have a an existing driver that needs to be signed to load silently on Vista32. I've performed the following task, but always get a driver not signed error. 1) created a self signed test cert, loaded the public key version on the target machine, loaded both on my dev machine 2) created a cat file using inf2cat (from the latest win ddk) 3) signed the cat file using the test cert and signtool 4) verified the signature using sign tool 5) viewed the cat file and all looks ok 6) configured the vista machine to use test certs (test shows in all 4 corners) 7) tried loading the driver using devcon, pnputil and snetcfg -- always get the security error repeated the process but signed the .sys file, also no avail. our normal install is: snetcfg.exe -v -l ourinf.inf -m ourinf_m.inf -c s -i nt_ourinf however, I get the error if I use devcon to install ourinf.inf directly Someone told us we need to go through whql to resolve this, but the documentation seems to indicate otherwise. I'm guessing that there is something wrong with the .inf file? Thanks for all your help, Bob Sisson Robert Sisson Product Development Technical Specialist NCR Corporation xxxxx@ncr.com<mailto:xxxxx@ncr.com> | www.ncr.com<http://www.ncr.com/> --
  Message 4 of 24  
03 Nov 10 13:15
Bob Kjelgaard
xxxxxx@microsoft.com
Join Date: 16 Apr 2008
Posts To This List: 131
Re:Driver Signing for Vista 32
With all due respect, Don (and I hope you realize I really do respect you, man) - the method he wants to use to "silently load" his driver works for me, and has for years (we began using it regularly in automated testing in 2007). For maximum flexibility in our automated tests, we literally assemble test content, including many driver packages, from multiple sources- including quick fix builds from our own machines in a pinch (worse yet, sometimes we have stale old drivers nobody builds anymore- not that such a situation is allowed to last long). We automatically catalog everything and self-sign it AFTER it has been assembled on the test machine in the lab. Literally we (fully automated) assemble everything, sign it on the fly, and start running. We don't use any secret techniques to do this- I worked from the KMCS docs everyone refers to when I put this together. I don't/won't do UI automation, so I have to have "signed drivers" (and I have tests where bus drivers report HWIDs that get matched and the drivers for those also have to silently install, and even some where those drivers are in turn busses). I wouldn't use this method if it had any serious flaws- I have enough bugs to triage most of the time as it is. I'm certain the logo information can be inferred to apply to end-user systems, which will not / should never be enabling test signing. There a self-signed cert will definitely not work. -----Original Message----- 32 bit drivers do not have to be signed, but to load silently you need a WHQL signature not a selfsign. See http://www.microsoft.com/whdc/winlogo/default.mspx for details. Don Burn (MVP, Windows DKD) Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr "Sisson, Robert" <xxxxx@ncr.com> wrote in message news:152237@ntdev: > I'm a newbie with driver signing. We have a an existing driver that needs to be signed to load silently on Vista32. I've performed the following task, but always get a driver not signed error. > > 1) created a self signed test cert, loaded the public key version on > the target machine, loaded both on my dev machine > 2) created a cat file using inf2cat (from the latest win ddk) > 3) signed the cat file using the test cert and signtool > 4) verified the signature using sign tool > 5) viewed the cat file and all looks ok > 6) configured the vista machine to use test certs (test shows in all 4 > corners) <...excess quoted lines suppressed...> --- NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
  Message 5 of 24  
03 Nov 10 13:42
Gary Little
xxxxxx@comcast.net
Join Date: 08 Apr 2009
Posts To This List: 964
RE: Driver Signing for Vista 32
On 32 bit, you should not need to sign the driver for it to load and function. All 64 bit drivers MUST be signed. However, what you way be getting is the WHQL warning and that you cannot absolve until you submit the driver to WHQL and the driver is then signed with the WHQL certificate. Gary G. Little H (952) 223-1349 C (952) 454-4629 xxxxx@comcast.net From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Sisson, Robert Sent: Wednesday, November 03, 2010 11:20 AM To: Windows System Software Devs Interest List Subject: [ntdev] Driver Signing for Vista 32 I'm a newbie with driver signing. We have a an existing driver that needs to be signed to load silently on Vista32. I've performed the following task, but always get a driver not signed error. 1) created a self signed test cert, loaded the public key version on the target machine, loaded both on my dev machine 2) created a cat file using inf2cat (from the latest win ddk) 3) signed the cat file using the test cert and signtool 4) verified the signature using sign tool 5) viewed the cat file and all looks ok 6) configured the vista machine to use test certs (test shows in all 4 corners) 7) tried loading the driver using devcon, pnputil and snetcfg -- always get the security error repeated the process but signed the .sys file, also no avail. our normal install is: snetcfg.exe -v -l ourinf.inf -m ourinf_m.inf -c s -i nt_ourinf however, I get the error if I use devcon to install ourinf.inf directly Someone told us we need to go through whql to resolve this, but the documentation seems to indicate otherwise. I'm guessing that there is something wrong with the .inf file? Thanks for all your help, Bob Sisson Robert Sisson Product Development Technical Specialist NCR Corporation <mailto:xxxxx@ncr.com> xxxxx@ncr.com | <http://www.ncr.com/> www.ncr.com --- NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer __________ Information from ESET Smart Security, version of virus signature database 5588 (20101103) __________ The message was checked by ESET Smart Security. http://www.eset.com --
  Message 6 of 24  
03 Nov 10 14:18
Bob Sisson
xxxxxx@ncr.com
Join Date: 03 Nov 2010
Posts To This List: 4
RE: Driver Signing for Vista 32
Thanks everyone, I'm still a little confused: Our original plan to eventually sign the drivers with a cross certified key. We have already purchased the certificate for this. There are instructions in the technet documentation for this, including the "Windows Kernal-Mode Code Signing Walkthrough" document and the step by step guide for signing and staging device drivers. I get no errors when signing the cat or sys files, and the signatures verify fine with the signtool. I have loaded the certs in trusted root store, but not the trusted publisher store -- I will try that next. We are also looking at whql for this, but I would like to avoid that if possible. Thanks again -- appreciate any more pointers
  Message 7 of 24  
03 Nov 10 14:41
Bob Sisson
xxxxxx@ncr.com
Join Date: 03 Nov 2010
Posts To This List: 4
RE: Driver Signing for Vista 32
Also did not work. Looking at references from MS (from above) I should be able to do this: Windows Vista solves these problems by allowing vendors and IT departments to sign and publish drivers by using an Authenticode signature. IT departments can configure Windows to treat drivers that they signed as equivalent to drivers that were signed by Microsoft, thus allowing an IT department to silently deploy drivers across their corporation, even updating in-box drivers. Vendors can quickly deploy emergency fixes to their customers without waiting for a signature from Microsoft. Meanwhile, because these drivers are signed, IT departments and end users can be secure, knowing that the drivers have not been altered in any way since they were published. Further, users know the source of the drivers because the signature also identifies the publisher. These third-party signatures complement the signatures that Windows Hardware Quality Labs (WHQL) gives. The third-party signatures guarantee driver integrity, but do not imply any level of testing or quality. The signatures that are given as part of the Windows Logo Program not only verify driver integrity, but also indicate a level of quality that is based on tests run by WHQL.
  Message 8 of 24  
03 Nov 10 15:03
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 8327
Re: Driver Signing for Vista 32
xxxxx@ncr.com wrote: > Our original plan to eventually sign the drivers with a cross certified key. We have already purchased the certificate for this. There are instructions in the technet documentation for this, including the "Windows Kernal-Mode Code Signing Walkthrough" document and the step by step guide for signing and staging device drivers. That works fine for KMCS, but this has no effect on "silent install". The install-time signature checking is entirely separate from the 64-bit KMCS checking. There was an article on this very topic by someone very dear to me in this month's NT Insider. > I get no errors when signing the cat or sys files, and the signatures verify fine with the signtool. That's fine for 64-bit KMCS, but is useless for install-time checking. > We are also looking at whql for this, but I would like to avoid that if possible. If you hope to release this outside of your own office, WHQL is the only way to get silent installs. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 9 of 24  
03 Nov 10 15:14
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 3433
Re: Driver Signing for Vista 32
On Wed, Nov 3, 2010 at 3:02 PM, Tim Roberts <xxxxx@probo.com> wrote: > If you hope to release this outside of your own office, WHQL is the only > way to get silent installs. Well no it isn't. You have to pre-install an acceptable cert on the target machine and then install your driver. No pop-uppys. This is covered under 'how to release sign a kernel module' in the walk through. Mark Roddy
  Message 10 of 24  
03 Nov 10 15:48
Bob Kjelgaard
xxxxxx@microsoft.com
Join Date: 16 Apr 2008
Posts To This List: 131
RE: RE:Driver Signing for Vista 32
>> I get no errors when signing the cat or sys files, and the signatures verify fine with the signtool. I have loaded the certs in trusted root store, but not the trusted publisher store -- I will try that next. << This is a bit abstracted, but it should help understanding this process. Silent installation of the driver requires a trusted publisher. That is why the KMCS document says to put the certificate there. Even if the root for your certificate says you can be trusted we will still verify each time someone who is not a trusted publisher tries to put something on a machine. You have to put it in root, because even if you're a "trusted publisher" we can't be sure it's really you if the certificate chain ends in an unknown [hence untrusted] root. A self-signed cert has no chain, so it has to be both places. (BTW [I could be wrong about this part- the rest I am quite sure of] this bit about adding to root may only work when test signing mode is enabled). >> Windows Vista solves these problems by allowing vendors and IT departments to sign and publish drivers by using an Authenticode signature. IT departments can configure Windows to treat drivers that they signed as equivalent to drivers that were signed by Microsoft, thus allowing an IT department to silently deploy drivers across their corporation, even updating in-box drivers. Vendors can quickly deploy emergency fixes to their customers without waiting for a signature from Microsoft. Meanwhile, because these drivers are signed, IT departments and end users can be secure, knowing that the drivers have not been altered in any way since they were published. Further, users know the source of the drivers because the signature also identifies the publisher. These third-party signatures complement the signatures that Windows Hardware Quality Labs (WHQL) gives. The third-party signatures guarantee driver integrity, but do not imply any level of testing or quality. The signatures that are given as part of the Windows Logo Program not only verify driver integrity, but also indicate a level of quality that is based on tests run by WHQL. << Yes, this is how it is supposed to be. To address another issue mentioned a couple of times here, let's be clear. You start out untrusted. WHQL starts out trusted (call it an "inbox certificate"). So as far as this silent install thing goes- yes, THE VERY FIRST TIME we see something from you, they'll get a popup asking if you can be trusted (or you need an install procedure that installs your certificate appropriately, and that action will also require their approval, so the first one is never free without WHQL). But if you've got a proper cross-certified certificate and they elect to make you a trusted publisher, then you chain to that "inbox" stuff, and we will trust you from henceforth- so all future drivers from you [not just that one] will install silently. I know this works- I use a multiport serial card with Authenticode (not WHQL) signed drivers on the X64 machine I'm writing this from, and if I mark the checkbox saying to trust all future content from them when I install the main driver, it silently installs all the ports after the adapter's driver starts. If I don't, then I get asked again to verify trust for each of the ports as it gets enumerated. >> Also did not work. Looking at references from MS (from above) I should be able to do this: << Yes you should- the people providing my multiport serial card could, and as I said before, I've been doing it myself (in the self-signed test form) for a really long time now. There are also aids provided to help you and I diagnose problems when they arise. One of those is the setupapi logs I mentioned before, which, beginning with Vista, provide a lot more detail about what is going on when things like this break. What does that log say is wrong? You seem to be focused on the mechanics of the certificate, but it's not clear from the information presented so far, that this is what the problem actually is here.
  Message 11 of 24  
03 Nov 10 15:57
Thomas Divine
xxxxxx@pcausa.com
Join Date: 05 Aug 2010
Posts To This List: 635
Re: Driver Signing for Vista 32
Is there a difference in behavior for installations that are "legacy" (Non PnP) and PnP? I have a NDIS 5 protocol driver (signed binary) that can be installed as a legacy driver using the SCM. No pop-ups are seen. The same driver can be installed using an INF using netcfg. In this case there is a "this is an Authenticode-signed driver" pop-up. Both installs are on clean Vista or later machines. Thomas F. Divine -------------------------------------------------- From: "Mark Roddy" <xxxxx@hollistech.com> Sent: Wednesday, November 03, 2010 3:14 PM To: "Windows System Software Devs Interest List" <xxxxx@lists.osr.com> Subject: Re: [ntdev] Driver Signing for Vista 32 > On Wed, Nov 3, 2010 at 3:02 PM, Tim Roberts <xxxxx@probo.com> wrote: >> If you hope to release this outside of your own office, WHQL is the only >> way to get silent installs. > > Well no it isn't. You have to pre-install an acceptable cert on the > target machine and then install your driver. No pop-uppys. This is > covered under 'how to release sign a kernel module' in the walk > through. > > Mark Roddy <...excess quoted lines suppressed...>
  Message 12 of 24  
03 Nov 10 16:11
Bob Kjelgaard
xxxxxx@microsoft.com
Join Date: 16 Apr 2008
Posts To This List: 131
RE: Driver Signing for Vista 32
These behaviors are by design, and yes, they are different. On a 64-bit system, though, the signing rules still apply to the legacy case as far as loading (not installing) goes. Nothing untrusted can be loaded. -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine Sent: Wednesday, November 03, 2010 12:56 PM To: Windows System Software Devs Interest List Subject: Re: [ntdev] Driver Signing for Vista 32 Is there a difference in behavior for installations that are "legacy" (Non PnP) and PnP? I have a NDIS 5 protocol driver (signed binary) that can be installed as a legacy driver using the SCM. No pop-ups are seen. The same driver can be installed using an INF using netcfg. In this case there is a "this is an Authenticode-signed driver" pop-up. Both installs are on clean Vista or later machines. Thomas F. Divine -------------------------------------------------- From: "Mark Roddy" <xxxxx@hollistech.com> Sent: Wednesday, November 03, 2010 3:14 PM To: "Windows System Software Devs Interest List" <xxxxx@lists.osr.com> Subject: Re: [ntdev] Driver Signing for Vista 32 > On Wed, Nov 3, 2010 at 3:02 PM, Tim Roberts <xxxxx@probo.com> wrote: >> If you hope to release this outside of your own office, WHQL is the >> only way to get silent installs. > > Well no it isn't. You have to pre-install an acceptable cert on the > target machine and then install your driver. No pop-uppys. This is > covered under 'how to release sign a kernel module' in the walk > through. > > Mark Roddy <...excess quoted lines suppressed...>
  Message 13 of 24  
03 Nov 10 16:27
Bob Sisson
xxxxxx@ncr.com
Join Date: 03 Nov 2010
Posts To This List: 4
RE: Driver Signing for Vista 32
Thanks, I figured out the root of my first problem -- the original files given to me had a signature, and oversigned it and caused some issues. Undid all of that and it works as expected, except my customer now no longer wants the first time do you trust us dialog box - the first time. Looking at the post by Bob K - > You start out untrusted. WHQL starts out trusted (call it an "inbox certificate"). So as far as this silent install thing goes- yes, THE VERY FIRST TIME we see something from you, they'll get a popup asking if you can be trusted (or you need an install procedure that installs your certificate appropriately, and that action will also require their approval, so the first one is never free without WHQL). We need to go through WHQL to make our customer happy. Thanks, I learned a bunch Bob
  Message 14 of 24  
03 Nov 10 20:02
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 8678
Re: Driver Signing for Vista 32
>1) Did you put the certificate in the local machine's TrustedPublisher and Root stores (and it must >be localmachine, not the logged-in user's store it will otherwise default to, as parts of the install run in >a system and not a user context)? That may be what you meant by "loaded it" but that's not at all clear >to me. More so. If a "toy" cert is created using MAKECERT without having a good root cert (self-signed), then it is a good idea to a) open it using the shell ext b) extract the public part of "Root Agency" from it and c) install this extracted Root Agency to Local Machine Trusted Roots. Then install the whole cert to Local Machine Trusted Publishers (or omit this, this will cause the yellow "do you trust?" dialog box from SetupCopyOEMInf). No need to turn the OS to the mode with "Test" in the corners. At all. -- Maxim S. Shatskih Windows DDK MVP xxxxx@storagecraft.com http://www.storagecraft.com
  Message 15 of 24  
03 Nov 10 20:04
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 8678
Re: Driver Signing for Vista 32
>"Windows Kernal-Mode Code Signing Walkthrough" Sorry, but you're mixing KMCS with PnP signing. KMCS requires cross-certs. PnP signing does not. KMCS does not use cert stores on the machine. PnP signing uses them. KMCS is checked on binary load, PnP - in SetupCopyOEMInf. -- Maxim S. Shatskih Windows DDK MVP xxxxx@storagecraft.com http://www.storagecraft.com
  Message 16 of 24  
03 Nov 10 20:11
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 8678
Re: RE:Driver Signing for Vista 32
>You have to put it in root, because even if you're a "trusted publisher" we can't be sure it's really you if >the certificate chain ends in an unknown [hence untrusted] root. More so. "The chain must end with a trusted root" condition is checked earlier then "being in Trusted Publishers" one. If the first condition is not met - then this considered to be _bad digital signature_, and cause the red dialog box (same way as if some bytes were altered). Only if all crypto is OK and the root is in Trusted Roots (i.e. the digital signature is good) - the "being in Trusted Publishers" is checked. KMCS does not use cert stores, and thus requires the cross-cert, which is the "trusted root" embedded to the binary itself. >A self-signed cert has no chain, A chain of 2 items - Root Agency, then Your Toy Company. Put Root Agency to roots and Your Toy Company to publishers, after this all works OK (2003+ at least, there were issues on XP but I don't remember what they were). -- Maxim S. Shatskih Windows DDK MVP xxxxx@storagecraft.com http://www.storagecraft.com
  Message 17 of 24  
04 Nov 10 05:13
Bruce Cran
xxxxxx@cran.org.uk
Join Date:
Posts To This List: 214
Re: Driver Signing for Vista 32
On Wed, 3 Nov 2010 15:56:11 -0400 "Thomas F. Divine" <xxxxx@pcausa.com> wrote: > Is there a difference in behavior for installations that are > "legacy" (Non PnP) and PnP? > > I have a NDIS 5 protocol driver (signed binary) that can be installed > as a legacy driver using the SCM. No pop-ups are seen. > > The same driver can be installed using an INF using netcfg. In this > case there is a "this is an Authenticode-signed driver" pop-up. Do you know if there's a way to install using netcfg via WiX/DifX? I'd like to move away from using the legacy method for my protocol driver but I can't find any documentation. -- Bruce Cran
  Message 18 of 24  
04 Nov 10 08:55
ntdev member 32323
xxxxxx@hotmail.com
Join Date:
Posts To This List: 843
Re: Driver Signing for Vista 32
On 11/04/2010 01:10 AM, Maxim S. Shatskih wrote: > KMCS does not use cert stores, and thus requires the cross-cert, > which is the "trusted root" embedded to the binary itself. Almost correct. The "trusted root" in this case is very likely an "MSCV root" certificate compiled into the boot driver loader. *This* is used to verify the cross-cert (and thus the whole chain). ("Trusted root" must always be something that is already on the machine. Otherwise this is not secure. It can also be a checksum of the top-level certificate, but *something* verifiable must be present.)
  Message 19 of 24  
04 Nov 10 09:03
ntdev member 32323
xxxxxx@hotmail.com
Join Date:
Posts To This List: 843
Re: Driver Signing for Vista 32
On 11/03/2010 09:29 PM, xxxxx@ncr.com wrote: > it works as expected, except my customer now no longer wants the > first time do you trust us dialog box - the first time. You could avoid that "first-time box" by pre-installing the publisher certificate to "Trusted Publishers", e.g. via ADS. Unless your customer is a company who wants to sell the driver packaged with hardware.
  Message 20 of 24  
04 Nov 10 12:24
Bob Kjelgaard
xxxxxx@microsoft.com
Join Date: 16 Apr 2008
Posts To This List: 131
RE: Re:RE:Driver Signing for Vista 32
A caveat (excellent series of posts, Max, I'll put that in first): >> Put Root Agency to roots and Your Toy Company to publishers, after this all works OK (2003+ at least, there were issues on XP but I don't remember what they were).<< << The process was designed for Vista and up- it working in any fashion for earlier OS is nice, but not directly intended. You will still get unsigned driver popups if the device setup class is one where a WHQL program existed at OS RTM- this applies only to WS03, and I don't know whether or not (and forgive me for this if you can, but I really don't WANT to know) this was updated in SPs. One painful memory of the last few years is having to revert to manual testing of the KMDF modem sample on WS03 because of this. There's a link for this somewhere on MSDN, but I'm not going to try to look up that kind of trivia- that's what search engines are for. FWIW, I didn't have problems using self-signed certs on XP (even Win2K, although we dropped that from automation eventually), but I also suspect we configured the OS to default to ignoring unsigned drivers, probably without knowing it. I can remember some curiosity about why it was working, but I don't recall a conclusive investigation, and since it was working, I had bigger problems to solve.
  Message 21 of 24  
04 Nov 10 22:55
Chris Aseltine
xxxxxx@gmail.com
Join Date: 23 Sep 2006
Posts To This List: 1049
RE: Driver Signing for Vista 32
Bob Kjelgaard wrote: > FWIW, I didn't have problems using self-signed certs on > XP (even Win2K, although we dropped that from automation > eventually), but I also suspect we configured the OS to default > to ignoring unsigned drivers, probably without knowing it. So just out of curiosity, you're saying that by following this process (making the fake cert, installing it as trusted root, signing your driver with it), you can get a silent device install on XP? No hardware wizard, no warning box ... at least for non-logo setup classes?
  Message 22 of 24  
05 Nov 10 06:57
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 8678
Re: Driver Signing for Vista 32
> So just out of curiosity, you're saying that by following this process (making the fake cert, installing it >as trusted root, signing your driver with it), you can get a silent device install on XP? No hardware >wizard, no warning box ... at least for non-logo setup classes? I second this question. I've managed to do silent install of System class using this way in 2003+, but not in XP. -- Maxim S. Shatskih Windows DDK MVP xxxxx@storagecraft.com http://www.storagecraft.com
  Message 23 of 24  
05 Nov 10 07:00
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 8678
Re: Driver Signing for Vista 32
>> KMCS does not use cert stores, and thus requires the cross-cert, >> which is the "trusted root" embedded to the binary itself. > > Almost correct. The "trusted root" in this case is very likely an "MSCV > root" certificate compiled into the boot driver loader. Thanks for correction. -- Maxim S. Shatskih Windows DDK MVP xxxxx@storagecraft.com http://www.storagecraft.com
  Message 24 of 24  
05 Nov 10 13:10
Bob Kjelgaard
xxxxxx@microsoft.com
Join Date: 16 Apr 2008
Posts To This List: 131
RE: Re:Driver Signing for Vista 32
>>> > So just out of curiosity, you're saying that by following this process >(making the fake cert, installing it as trusted root, signing your >driver with it), you can get a silent device install on XP? No hardware wizard, no warning box ... at least for non-logo setup classes? I second this question. I've managed to do silent install of System class using this way in 2003+, but not in XP. <<<< Max, this is the phrase you and Chris are referring to: "FWIW, I didn't have problems using self-signed certs on XP (even Win2K, although we dropped that from automation eventually), but I also suspect we configured the OS to default to ignoring unsigned drivers, probably without knowing it" Meaning I have my doubts that this mechanism works on XP- it seemed to, but I've heard from credible sources [including you] that it doesn't- I've not had free time to investigate why something mundane like this works when there are many things that aren't working and getting them working is much more important. I don't have end-to-end control of the automation, and silently ignoring unsigned drivers would be a useful way to pre-configure a test system- but that's just a guess. I was curious, but I didn't have enough time to get anywhere trying to sort it out. Without getting into why- it is now moot for me. I deliberately prefaced it by FWIW, as well- meaning it might be worth nothing- I can't really tell. That was my experience- it worked, or at least seemed to.
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 02:31.

Contact Us - Osr Online Homepage - Top

Copyright ©2012, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license