Mark Minasi's Windows Networking Tech Page
Issue #76 March 2009

Document copyright 2009 Mark Minasi; please see below for info on subscribing, unsubscribing or copying portions of this text.

What's Inside

  • News
    • Join Me At a Seminar
    • The Server 2008 Seminar is Now a 15-CD Audio Set, XP and Vista Seminars available on CD also
    • The MR&D Forum Meeting 19-22 April is This Month
  • Tech Section
    • Solving the "This Driver Isn't Signed" Problem in 64-Bit Windows
  • Conferences
  • Bring a Seminar to Your Site
  • To Subscribe, Unsubscribe, Read Old Newsletters or Change Your Email Address


Hi all —

This month, a bit of PKI sneakiness in order to mollify any version of 64-bit Windows, which has a somewhat misplaced obsession with signed drivers and kernel executables.  In short, I'll show you how you can fool 64-bit Windows into thinking that that driver that you really need to use, but that isn't signed -- which normally means that 64-bit Windows rejects it -- is indeed signed, and so it accepts that driver with open arms.  It's been of help to me a couple of times in 64-bit Vista and 2008 and I think you'll find it useful but first... a word from our sponsor.

The Server 2008, Vista and XP Seminars Available As Audio Sets

I'll keep it short and sweet:  given the current economic conditions, I know that some of you would like to get to my 2008 seminar, but that there is no way that you will be able to convince the boss to let you travel or even leave the office anytime soon.  For you folks, I've recorded the Server 2008 class, my Vista Support class and my XP Support classes in their entirety and you can buy them on a stack of CDs for under a quarter of the price of attending the seminar.

The newest is the Server 2008 set and I want everyone to be able to afford this set, so I've priced it the same as I did our Server 2000 audio set nine years ago.  I've also posted online a free 18 minute sample from the Hyper-V coverage that I hope you'll like whether you buy the set or not.  More info at, and I hope you find it a convenient and entertaining way to get the ins and outs of 2008.  You can find out about my other audios (XP, Vista, etc) at; there are sample audio downloads for all of the class CD sets.

The MR&D Forum Meeting 19-22 April is This Month

For the fourth year in a row, I'm hosting a conference in Virginia Beach under the aegis of our MR&D forum.  It may be the best deal you'll find this year conference-wise ($450 attendee fee for a four-day conference) and we've got some great speakers as always.  More info at  Come join us by the shores of the beautiful Chesapeake Bay!

Dave Solomon's Teaching "Windows Internals" in London in April

(The lucky dog; it's been too long since I've been in London!  Gotta set up a class there some time...)  Find out more at  You know Dave -- he and Mark Russinovich write the Microsoft Press Windows Internals book.  You'll learn so much your head will explode.

Tech Section

Solving 64-Bit Windows' "I Only Want Signed Drivers!" Tantrums

I love 64-bit Windows.  I love the ability to stick 8 gigs of RAM on a laptop, allowing me to run several virtual servers, each of which I can equip with 1.5 GB of RAM.  (Life's too short to wait for Server 2008 to get things done in 512 MB of RAM, y'know?)  I love how much snappier Adobe Lightroom is when it's no longer shackled to the 2 GB limits that 32-bit Windows requires.  And I especially love that the main problem with 64-bit Windows -- the lack of 64-bit drivers -- is largely a thing of the past, save for those cases where vendors use the new architecture as a way to force you to upgrade (and yes, I am talking to you, HP printer division and Cisco VPN folks).

Once in a while, though, I run up against the the thing that I most don't like about 64-bit Windows:  the iron rule of driver signing.  Ever since XP and 2003, the 64-bit versions of Windows have refused to load kernel executables or device drivers unless those executables and drivers are digitally signed.  Load a driver that's not signed, and 64-bit Windows pops up some scary-looking message essentially saying, "take a walk, buddy, and take your unsigned driver with you... I mean you don't really know where this thing's been, do you?"  You can get around it by pressing F8 every time you boot and disabling driver signing, but that's a pain.  There was once, briefly, a setting in bcdedit that would let you tell Windows to always skip driver signing, but Vista SP1 put an end to that -- and besides, I don't want Windows to ignore checking the signatures on all drivers, I just want it to allow me to run the occasional unsigned driver.

Look, I understand the whole thought process behind this totalitarian approach, which I understand runs something like this:

  • Unsigned drivers cause the vast majority of Windows bluescreens.
  • Unknowing users don't know that, and so blame Microsoft for blue screens
  • This really irritates people at Microsoft and in particular Dave Cutler, Windows' Architectus Maximus
  • Dave wants to make it easy to finger the culprit of any given blue screen
  • Signing a driver carries with it something of a statement of personal confidence in that driver (and here, I feel, is where the whole thing falls down a bit:  signing a driver says you wrote it, not that it lacks bugs), so...
  • 64-bit Windows requires that all drivers and kernel executables be signed.

It all just seems a bit heavy-handed for my taste -- sort of like, oh, say, scaring a large room full of people into thinking that you've just released a bunch of malaria-infected mosquitoes into the air to make a point about poverty.  Anyway, this month I wanted to offer a workaround for those who run 64-bit systems and really need to run an unsigned driver now and then.  The workaround?  Create your own driver signing certificate and sign the driver or application yourself!  Here are the steps.

Get the SDK

First, we need some tools, and the SDK has 'em.  Go to and download the "Win32 SDK."  There are several versions, so pick whichever you like.  I download the one in ISO format, burn the ISO to a DVD and install the SDK from that DVD.  You might actually want to do this on a test machine or virtual machine, as the SDK's kind of big. 

Open a Command Prompt with the SDK on its Path

Once you've got the thing installed, click Start / All Programs / Microsoft Windows SDK v6.1, and then under that choose "CMD Shell." If you're running on Vista or later, be sure to elevate that task by right-clicking the "CMD Shell" icon, choose "Run as Administrator," and confirm the UAC prompt.  Don't use a regular old command prompt, as the "CMD Shell" shortcut adds items to your path -- without them, you'd get one of those " not recognized as an internal or external command..." error messages.

Create a Place to Hold the Certificate Files

On your drive, create a folder to contain the certificate that you're going to create and then switch over to the folder by typing:

md \mycerts
cd \mycerts

We're looking to end up with a code signing certificate in a particular format called an "Authenticode" format.  To accomplish that, we've got to do three steps: "makecert" will create a certificate, "cert2spc" will convert it to Authenticode format, and "pvk2pfx" will convert the private key in that certificate into Microsoft's "PFX" format.  Armed with a PFX file and a fourth tool, "signtool," we can then sign any executable that we like. 

Create the PVK and CER files

The "makecert" command, which creates our private key and certificate file, will look like

makecert -sv nameofpvkfile -a sha1 -eku -r -ss Root -len 1024 -sr localMachine -n CN="some descriptive name" nameofcerfile

The long string of numbers is the "object ID" (OID) and it is essential, as OIDs tell software what a certificate's good for.  To make this work, we specify a name for a PVK file (which stores a private key of the certificate that we're creating), a CER file (the certificate we're creating), and whatever descriptive label you like for your certificate.  For example, on my system I typed

makecert -sv codesigner.pvk -a sha1 -eku -r -ss Root -len 1024 -sr localMachine -n CN="Mark's Test Lab" codesigner.cer

If you typed that right -- it's truly ugly, so don't be discouraged if you get it wrong the first time (I'm a big believer in cut and paste), then you'll get a simple dialog box named "Create Private Key Password" asking you for a password and to confirm that password.  Certificates are built around the idea of a pair of encryption keys, the public and the private.  PKI ("public key infrastructure," a common acronym for "certificate-related stuff") password-protects private keys because if just anyone got your certificate and private key, then they could code-sign things in your name, so unless you want the next worm going out signed by you, you should normally pick a decent password and protect it for your private key.  In this case, however, you're creating a certificate whose only goal in life is to make your copy of 64-bit Windows happy -- the certificate just claims that you own it, but can't prove it and so is of no value to anyone outside your organization -- so pick whatever password you like for this exercise.  I'm going to use "leafwood" as it's a moderately strong passphrase -- more than seven characters and not just a single English word -- for this example.

Immediately after you choose the password, typing it in twice and clicking OK, you'll get another dialog box asking you to enter the private key for the new certificate.  (Apparently this is intended to be a security measure against people with no short-term memory at all being able to create code-signing certificates.)  You'll get a "Succeeded" response and two new files in that folder -- in my case, I've now got "codesigner.cer" and "codesigner.pvk."

As a side-effect, makecert also installed this new certificate in your certificate store.  You can see this by setting up a couple of MMC snap-ins or, rather, by installing two copies of the Certificate Manager snap-in, one showing you the certificates associated with your user account and one showing you the certificates associated with your machine's certificate store.  Here's how:

  • Start up mmc.exe
  • Click File / Add/Remove Snap-in.
  • In the "Add or Remove Snap-ins" dialog, click "Certificates" and Add.
  • You'll get a gray wizard panel asking, "This snap-in will manage certificates for:" and then offers three radio buttons: "My user account," "Service account," or "Computer account"
  • Click "My user account" and then Finish
  • Still in the "Add or Remove Snap-ins" dialog, again click "Certificates" and Add.
  • This time, click the "Computer account" radio button, Next, and Finish.
  • Click OK to close the "Add or Remove Snap-ins" dialog box.  It'll look something like the following screen shot:

  1. You can see your new certificate by opening either the "Certificates - Current User" or "Certificates (Local Computer)" icon and then, under that, the "Trusted Root Certification Authorities / Certificates folders.  In either case, you'll see your new cert, as in the following screen shot:

You can see the cert that I created as the fifth down in the right-hand-side pane.  It isn't anywhere else in your certificate stores at this point.

Create an SPC File from the CER File

This next step has much easier syntax, I promise:

cert2spc existing-cer-file-name name-of-SPC-file-to-create

In my case, I just type

cert2spc codesigner.cer codesigner.spc

And again I get "Succeeded."  (Apparently it's true, nothing breeds success like success.)

Build a PFX File from the PVK File

The tool that's actually going to take our we-made-it-up-to-make-Windows-happy certificate and use it to sign the driver, application or whatever that we need to get signed so that 64-bit Windows likes it is an EXE named "signtool," and signtool wants to see a PFX file rather than a PVK file.  "Pvk2pfx" produces a PFX for us, and it looks like

pvk2pfx -pvk existing-pvk-filename -pi existing-password-on-privatekey -spc existing-spc-filename -pfx pfx-file-to-create -po password-to-put-on-private-key-in-pfx

We've already built the "codesigner.pvk" and "codesigner.spc" files, put a password of "leafwood" on the private key and might as well assign the same one to the pfx file, so the command looks like

pvk2pfx -pvk codesigner.pvk -pi leafwood -spc codesigner.spc -pfx codesigner.pfx -po leafwood

Pvk2pfx is the most taciturn of the apps we'll look at today, and emits no success messages.

Sign the App!

Finally, we're ready to go.  From now on, we can sign as many apps as we like, needing only codesigner.pfx and the password, "leafwood."  Sign an application or driver as follows:

signtool sign /f pfxfilename /p privatekeypassword /d "short description" /v nameofexefile

For example, I'll use this to sign a copy of chml.exe, my tool for experimenting with Windows integrity levels.  Assuming there's a copy of chml.exe in the mycert folder, I'd type

signtool sign /f codesigner.pfx /p leafwood /d "Windows integrity file/folder tool" /v chml.exe

That gets some output that looks like

E:\mycert>signtool sign /f codesigner.pfx /p leafwood /d "Windows integrity file /folder tool" /v chml.exe
The following certificate was selected:
Issued to: Mark's Test Lab
Issued by: Mark's Test Lab
Expires: 12/31/2039 7:59:59 PM
SHA1 hash: 5846213EB951EE384B64A4DCE697F70CEAF3FA03

Done Adding Additional Store

Attempting to sign: chml.exe
Successfully signed: chml.exe

Number of files successfully Signed: 1
Number of warnings: 0
Number of errors: 0

You will now find that 64-bit Windows likes your application or driver just fine.  Validate it like so (I've tried this on Vista, 2008, Windows 7 and 2008 R2, haven't on XP so I don't know exactly what the UI looks like on XP):

  • Right-click on the application or driver that you just signed.
  • Choose Properties.
  • You should have a tab "Digital Signatures;" click it.
  • You'll see a "Signature list," and there should be one in the name of whatever descriptive name you gave makecert.  For example, mine ("Mark's Test Lab") looks like this:

You can also click on that line in the "Signature list" field and then "Details" and you'll see something like this figure, which conveys good news:

The good news, in case you're wondering, is "This digital signature is OK."

Making Other Systems Accept the Signed Driver

Clearly this is a solution of limited value, as the only copy of 64-bit Windows that is happy with your app/driver now is the one that you just did the work on.  The signature on the driver only works there because makecert installed the root certificate for your driver signature in your local driver store.  Thus, if you were to copy the signed version of chml to another computer, that computer wouldn't be able to validate the signature on the EXE, and you'd be back where you started.  Try it -- copy the signed chml (or whatever you signed) to another system and examine its digital signature's status as we just did above, and you'll see something like this:

To be able to distribute something that you've signed, then, you must also distribute (and install) a cert with the app.  To do that, copy the PFX file to the computer you just copied the application/driver to.  Right-click the PFX file and choose "Install PFX."  That starts a wizard as follows:

  • Click next to skip opening page
  • At the "File to Import" page, click Next 
  • Next, you'll see a "Password" page that wants the private key's password -- the password that you specified in the "-po" option of pvk2pfx.  (Remember we've been using "leafwood."  Don't bother checking anything else, and click Next
  • This "Certificate Store" page is important, as it says where to install the cert, and you do not want Windows to choose a location, as it guesses wrong.
  • Click the "Place all certificates in the following store" radio button and then the Browse button
  • You'll get a dialog box showing you where the certs can go; check the box labeled "Show physical stores"
  • Find "Trusted Root Certification Authorities" and click the plus sign next to it so that you can choose "Registry."
  • Click OK to return to the wizard which should now look like the following figure.
  • Click Next and Finish. You'll get a confirmation message like this:
  • Click Yes to dismiss it.
  • Click OK to clear the "successful import" dialog box.

Check the "Digital Signature Details" on your signed app, and you'll see that it's fine now.  Or... all that clicking irritates you (as it does me) and you're using a modern OS, here's a one-liner that does the same thing:

certutil -p leafwood -importpfx codesigner.pfx

Make Windows Accept Your Cert

Now, Windows wants your cert to be cross-signed by Microsoft, which costs money, but you can tell Windows 7 (I've not tested Vista) to accept certs that aren't signed by Microsoft with this command, executed from an elevated command prompt:

bcdedit /set testsigning on

This produces one side-effect:  Windows shows "Test Mode" in the lower right-hand corner of the desktop.

I hope this is useful!


Where Rhonda and I will be in the next few months:

Windows and Exchange Connections Orlando March 15-18

This week, the Windows Connections folks are the first out of the gate (conference-wise) with their Windows/Exchange show.  (They also do a developer-centric show the following week in the same location for the SQL, .NET, SharePoint and other crowds.)  I'll be keynoting as well as doing breakouts on "Hyper-V Without the Hype," "IPv6 for the Reluctant," and "Securing Modern Windows Systems."  Rhonda will help you head off true Active Disaster with "Failed Sysvol Replication can Wreak Havoc in your Network" and then demystifies Windows' deployment tools with "Create Your Own Unattend Answer Files for Vista and Server 2008 Using Windows System Image Manager (WSIM)" and "Windows Deployment Service (Microsoft's New RIS): Why It's Worth A Look!"

More info at  See you there!


TechEd US Los Angeles May 11-15

This year, Rhonda and I get to do the the TechEd preconference session introducing the world to Windows 7.  But that's not all:  I'll also offer a breakout session presenting an overview of the neat new Active Directory stuff in Server 2008 R2, and then I get to do three cool security talks.  First, I'll reprise my popular "12 Tips To Secure Your Network" talk, revised for 2009 realities, my new "Cracking Open Kerberos" talk, as well as "Uncovering Vista's Two Security Stars," an in-depth -- and contrarian -- look at User Account Control and Windows Integrity Levels.   Rhonda's got a fantastic session on Windows Deployment Services that you will not want to miss, as no one can explain this very useful tool as she can!

Find out more at

TechMentor Orlando June 22-26

They've asked Rhonda and me to return to the Royal Pacific Resort and I'm hoping to see some of you there!  Get more details at .

Microsoft's MMS April 27-May 1

Rhonda's at MMS in Vegas this year (I wasn't invited <sniff, sniff!>) doing some really cool talks:  her WDS overview and "What's New in Windows Deployment in Windows 7."  If you're going to be in Vegas and want to see how to save a boatload of money on your rollout tools then don't miss these talks!

Info at .

Bring Mark to Your Site to Teach

I'm keeping busy doing Server 2008 and Vista seminars and writing, but I've still got time to visit your firm.  In just two days, I'll make your current NT techies into 2008, Vista, security, XP, Active Directory or 2003 experts.  (And better yet they won't have to sit through any Redmondian propaganda.)  To join the large educational, pharmaceutical, agricultural, aerospace, utility, banking, government, telecommunication, law enforcement, publishing, transportation, military and other organizations that I've assisted, either take a peek at the course outlines at, mail our assistant Jean Snead at, or call her at (757) 426-1431 (only between 1-5 Eastern time, weekdays, please).

Until Next Month...

Have a quiet and safe month. 

Please share this newsletter; I hope that it is a useful source of Windows technical information.  Please forward it to any associates who might find it helpful, and accept my thanks.  We are now at over 45,000 subscribers and I hope to use this to get information to every one of my readers. Many, many thanks to the readers who have mailed me to offer suggestions, errata, and those kind reviews.  As always, I'm at and please join us at the Forum with technical questions at  Thanks for letting me visit with you, and take care. 

To Subscribe/Unsubscribe, Read Old Newsletters or Change Your Email Address

To subscribe, visit To change e-mail or other info, link to  To unsubscribe, link to Visit the Archives at Please do not reply to this mail; for comments, please link to

All contents copyright 2009 Mark Minasi.  I encourage you to quote this material, SO LONG as you include this entire document; thanks.