Almost every author of a binary module has probably had someone ask about this at some point, because there’s always someone who has their user profiles stored on a network location, and therefore installed their modules on that network path and can’t get them to load because they get a warning that .Net “Failed to grant minimum permission requests.”

Before we get into this any further let me just say: by far the simplest thing to do is to create a local folder on your local hard drive, add that to your environment PSPathModules variable, and just install your modules there.

Other than that, the solution depends on the version of .Net that you’re using (you can tell by checking the $PSVersionTable.CLRVersion

The .Net 2.0 framework (and 3.0 and 3.5 and 3.5 SP1)

The problem is not a PowerShell problem at all, it’s a .Net problem. The .Net framework 2.0 (remember that PowerShell targets 2.0, and is actually based on .Net 1.1) didn’t trust assemblies loaded from network shares. You can fix that for an individual assembly or for a whole share using the Caspol tool.

A complete discussion of that tool and it’s myriad command-line options is beyond me, but for a simple solution, you can run this command specifying the server and share you want to load from (in my example the “Modules” share on the “ProfileServer” server).

Hopefully the only thing that needs explaning there is that 1.2 is the default “Local Intranet” group, and that CasPol.exe is in your Framework Runtime directory. Once you’ve run that, you’ll be able to import any modules that are in subdirectories of that share.

Note: You must run the version of CasPol.exe which is in the lcation defined by the GetRuntimeDirectory() command (it’s important to use the same version as the runtime you want to be affected).

You can read more about importing binary modules from network shares, including how it changed in .Net 3.5 SP1 and why it’s not automatically fixed in .Net 4 over on the PoshCode wiki.

Ok, that’s better than the default, whew! At least you can specify the prompt text and the domain and default user name … but there are so many other options that are missing from that dialog —like remembering my credentials for goodness sakes. I know many places forbid using the “remember” option for credentials, but why is that decision not up to me?

Well, I can’t make all of those options appear (at least, not without compiling a pinvoke function to call the Win32 API) nor can I force PowerShell to use the new Vista/2008 Credential function (which is Common Criteria compliant in Vista) instead of the older CredUIPromptForCredentials ... but I can give you the most requested feature for Get-Credential: a -Console option to force the prompt to happen in the console instead of in a “CredUI” pop up.

Note: I kind-of messed up here, this will break if you’re used to using the -Credential parameter for Get-Credential to provide a default user name. I’ll fix it shortly.

Even after you trust a specific authority, you haven’t trusted a script author — so any signed script you run will prompt you whether you want to allow it or not, like so:

The important thing to note here is that you’re really being asked not about the script, but about the author. If you choose the Never or Always options, the certificate that was used to sign the script is added to the appropriate certificate store (“Untrusted Certificates” or “Trusted Publishers”, respectively). To be clear: this happens for each every new author certificate, regardless of whether it’s signed by a self-signed cert (where you’ve already installed the root certificate in your root store) or a certificate issued by a commercial CA — there’s no loophole, no matter what anyone may have said in the past.

So, you see … the support for code signing is built into the core of PowerShell — and it’s really a shame not to take advantage of it. There are plenty of articles out there about how to sign your scripts, and more, so I’m not going to get into that much — I want to address the question of how hard it is to create the certificates in the first place (and finish by giving you a sample script which will generate and import them to your dev box with a single line command).

Generating Code Signing Certificates with OpenSSL

I’ve been talking up automatic code-signing for awhile now — basically, I think that any script editor that pretends to be a PowerShell script editor should be able to sign scripts at the push of a button, even every time you save the file. On top of that, I think that (like Microsoft’s Speech Macros app) they should be able to generate a self-signed code-signing script for you.

Someone emailed me the other day to ask how I proposed to do this, since MakeCert).aspx isn’t redistributable, and can’t be counted on to be installed… Well, as an answer I wrote a script which I’ll share here, using the open source OpenSSL for Windows to generate the certificates. It’s a bit more complicated than using MakeCert, but still not a huge thing. Basically, it’s six lines of code — each calling the OpenSSL executable.

There are two problems: first, half of those lines actually cause interactive prompts: asking you for your country and state, and email address, various passwords, etc. On top of that, the default OpenSSL.cnf file distributed with Windows doesn’t really give you a way to create certificates that can code sign, so if you went through all of those steps — you still wouldn’t be able to sign scripts

My solution to both problems is pretty straight-forward: customize the config file and run the req requests in -batch mode. Normally that would mean creating a custom OpenSSL.cnf config file with the specific values necessary — but in this case, I’ve made a PowerShell script to do it.

New-CodeSigningCert.ps1 can generate both the CA certificate and the code-signing certificate, and you can set it up to prompt you as little as possible, however, the point of this isn’t really to provide a solution, but to provide an example for the developers of editors and IDEs — so it’s still a bit rough, and it doesn’t try to guess your user name, email, and organization information from the environment.

Importing Certificates

Importing certificates into the Windows Certificate Store can be done with the graphical “CertMgr.msc”, but also with any of several command-line tools including WinHttpCertCfg.exe from the Windows Server Resource Kit, and CertMgr.exe from the Windows SDK... which of course, aren’t redistributable. Someone really needs to tell Microsoft to get on the ball with this stuff.

I actually realized recently that you can use System.Security.Cryptography.X509certificates.X509Store to load certificates, rather than the old COM object, which makes this even easier. The most basic step is to just import the new CA.crt certificate into the Root Store.

You no longer need to use the CAPICOM.Store COM object even though it’s basically available everywhere now, and is redistributable …

In either case, after that, you can sign PowerShell scripts using the Get-PfxCertificate cmdlet on the pfx file we generated earlier…

Of course, you could also use the CAPICOM.Store method to import the pfx certificate into the CurrentUser’s “My” store. In either case, if you try to execute a signed script, you can choose always from the prompt and the certificate will be imported to the current user’s “trusted publisher” store. Alternatively, you could import the certificate to the local machine’s “trusted publisher” store using the CAPICOM.Store again and now you won’t receive a prompt at all.

Using New-CodeSigningCert

I’ve attached uploaded the New-CodeSigningCert script to PoshCode.org, which includes all the features mentioned so far. It’s about 111 lines of code, and 41 lines of the config file, plus 69 and 56 lines of comments in each … all wrapped up into a single file so you can hopefully figure it out, learn it, and modify as you see fit.

I had also attached the script packaged with the OpenSSL, but as this post has aged, that seems like not so great an idea, since you really want the newer releases with bug fixes, particularly if you have a 64bit machine … the script needs to be stored in the same folder with OpenSSL.exe, and you can just unpack OpenSSL (there’s no need for an installer), but I just can’t be trusted to keep my local copy here up to date, sorry. :’(

Once you’ve got it installed, and have customized the default parameters in the script, you should be able to easily generate scripts for multiple developers, and/or import those certificates to thousands of computers using PowerShell Remoting