Once you’ve got your PowerShell all installed and have set up your first profile to auto-load … you’re going to want some scripts (well, maybe you’ll want to learn more about how to use PowerShell, but go with me on this)!

One of the best places to look for scripts is the PowerShell Code Repository, and although you can browse and search on the website, you can also do it using the PoshCode module (or the version 1 compatible script). These scripts include a Get-PoshCode cmdlet which you can use with search terms to get a list of scripts and cmdlets back, or with numeric IDs to download scripts (you’ll see what I mean later on, for now, go ahead and grab the appropriate version of that script).

I’m going to assume you put it into your AutoModules folder. If you grabbed the module, it should be saved to WindowsPowerShell\AutoModules\PoshCode\PoshCode.psm1 otherwise, to WindowsPowerShell\AutoModules\PoshCode.ps1 … but you may have run into a minor problem if you load the .ps1 version ). Both the module and the script are signed, but they are signed by my self-issued code signing certificate which your computer almost certainly doesn’t trust… You can use the signature to verify that the file hasn’t been modified since I signed it, but that’s about all (and even that’s a bit of a trick). To actually use the script (module), you’ll need to sign the script yourself (see the steps and how to get a certificate in part 2).

If you’re on CTP2, this would be a good time to get my Authenticode script module to help with signing, and to learn a little about those PoshCode cmdlets …

Using PoshCode to get a module.

Create a folder in your AutoModules folder named “Authenticode” ... and then inside it, try running Get-PoshCode Authenticode … You should get a list of 3 or more versions of my script, entitled “Get/Set Signature (CTP2)”. You want the latest version, so pick the one with the biggest number for the ID, and run Get-PoshCode 464. That should download it and save it. You’ll be able to load it using Add-Module (since Add-Module in the current CTP doesn’t care about code-signing), but first you need to create a settings file (it will tell you how, if you try to load it without setting it). change the CertificateThumbprint that’s set in the first line of code in that script — set it to the thumbprint of your personal code-signing cert (which you’ve hopefully imported into your certificate store).

Now you’ll be able to sign without specifying the certificate each time, and you’ll be able to pipe files in too, so you could, for instance, sign all the script files in a whole folder tree like:

So, here’s what I do.

First of all, I don’t actually put .ps1 scripts into the AutoModules folder, I have a separate AutoScripts folder, and I dot-source scripts from there, as well as loading ps1xml format files from it. I also specifically use a series of scripts there: Aliases.ps1, Variables.ps1, and EyeCandy.ps1. I assume that the functions of the first two are obvious, the last one is a modified version of the PSCX prompt and MOTD script to modify my prompt and startup message.

On top of the PoshCode script module and the Authenticode script module I mentioned earlier, which I use for signing and resigning, and the new CTP2 version of the PowerTab script module, I also use a source build of the upcoming PSCX 1.2 release (which needs a bunch of scripts to be useful, so I just renamed their 3-line profile.ps1 to PSCX.psm1 and stuffed the whole build with all it’s sub-folders into my WindowsPowerShell\AutoModules\PSCX). I also preload my PoshHttp module for downloading files from the web, and I a couple of functions (ellipsis and Get-PerformanceHistory).

Almost everything else I use I write into scripts (I even use the in-line cmdlet syntax to get full-power parameter parsing in a script file) which I put in directories by category inside my main WindowsPowerShell\Scripts directory (in my profile directory, and add to my path so that I can just run a script named “Get-GUID.ps1” by typing Get-GUID on the command-line.

Here’s the profile script off my laptop as an example — I basically use the same profile on all my PCs, and make changes to the “Variables” scripts on each PC to differentiate them. In fact, I have a sub-directory of my “WindowsPowerShell\Scripts” called “Work” which I even keep around at home (although I practically never use those scripts at home — they’re mostly for resetting servers and doing db queries, and only work from home when my VPN connection is up). Let me know if you have any questions.

Incidentally, I use “RemoteSigned for my Execution Policy — I wish there were a way to require signing for just my profile, because then this system would basically protect me from tampering with my auto-run scripts. However, I’m actually comfortable not worrying about it any more than I worry about viruses replacing the executable for Notepad++ on my thumbdrive or something — I do realize that this profile script could be simplified a lot if I replaced the signature checking with just using the “AllSigned” policy … but there’s two major problems with that:

1. I’m a PowerShell-ed developer — I spend a lot of time editing scripts and running them, and re-signing scripts that I’m working on (even though it’s just a matter of typing “sign” before I run a script) becomes an annoyance, such that if I were working in that environment, I’d inevitably have a “Sign-and-Run” script, which would really make me less secure, rather than more — for the average user, I do think that if you’re not writing scripts yourself on a daily basis, you should consider using AllSigned.

1. PowerShell 2 CTP2 doesn’t check signatures on modules, so even if I have it set to all-signed, it will load script modules and will let you dot-source any script using the add-module command, so I’d have to avoid modules altogether to really be 100% secure.

In order to keep the conversation going, and hopefully, include some of the Microsoft MVPs and PowerShell developers that don’t participate in the IRC channel at all, I’m going to post a summary of the conclusions we’ve drawn so far, and then outline a proposal for the repository.

In case you don’t know, PowerShell implements code-signing for scripts using x509 Certificates (basically, SSL certs with “Extended” use properties), but the signatures are just embedded in the script as a comment, much like PGP signatures in email. Depending on your settings, the engine will actually check the signature on a script before executing it, and refuse to execute it if the signature isn’t valid, for instance, if the script has been modified, or the certificate used to sign it can’t be traced to a trusted Certificate Authority.

PowerShell code-signing is inconvenient, and expensive. Scripts are only Valid if they are signed, unmodified, and the certificate traces back to a CA(Certificate Authority) that is in your Trusted Roots store (by default, basically, Microsoft’s, VeriSign, Thawte, and Comodo).

You can create your own “test” certificate (that is, one that you sign yourself), but scripts signed by that certificate will only work on that computer. This system works fine for large companies which typically have either a subscription for purchasing certificates, or their own in-house trusted CA, but not for small private developers or open source script sharing communities without financial motivation.

Because of this, to take advantage of PowerShell’s code-signing on your computer (that is, to set your ExecutionPolicy to “AllSigned” or “RemoteSigned”) you must do one of these things:

1. Make sure that all script authors rent and use code-signing certs which cost more than $150 a year.
2. Add a non-commercial root CA certificate (like CACert) to (all of) your computer(s), and offer your authors the option of going through the process of getting one of those instead.
3. Create a “community” CA … and try to figure out how to make sure the certificate is secure enough to convince people to use it (yeah, ok, this was partly my idea, and it’s really a bad idea).

1. Generate your own code-signing certificate (which can be self-signed) and just sign every script that you trust.

So far, it seems like that last option is the only one that’s going to fly, because although some developers are willing to buy certificates to sign software they’re going to sell … most scripters and sys-admins aren’t willing to buy one to share their certificates for free.

So. Here’s the base fact:

The PowerShell Code repository is a repository of user-provided code.

We can’t actually afford to audit all of the code that users submit, nor take responsibility for verifying the identity of every contributor, but we’d like to have a way to do so. The best way would be to give everyone a free CodeSigning certificate from Microsoft or one of the established CAs, but we can’t afford to do that, so here’s our proposal (although it may sound like it, none of this is written yet, I’m just trying to get some feedback on the ideas):

Rather than rely strictly on user login authentication, we will require that all (non anonymous) submissions be SIGNED, and the signing certificate (key) will be the user authentication mechanism. Essentially, any unsigned code will show up as written by “anonymous” ... and any signed code will show up with the identity from the signing certificate — the certificate must include an email address, and the first post by each key will be held back until the email address can be authenticated.

In addition to the author’s signature on a script, other users who have used the code (or read through it without finding any issues), can also sign it as a show of trust — they simply submit the exact same script as a modification, but with their signature in place of the author’s.

So users will sign scripts to say they trust them, and when you browse or search the repository, you’ll see a lists of the users who have signed each code-snippet. You can download a copy of the code with any of the signatures and verify the signature yourself…

Additionally, there will be a Get-PoshCode cmdlet which probably should:

• Mark the downloaded scripts as ‘remote’.
• Add the download permalink url in a comment upon download (to aid in discovering other signatures and in adding your signature).
• Handle a cache of “trusted” key/certs and choose a trusted author (if there is one) from multiple available downloads, and ask you if you want to add any of the signers to your trusted list — particularly if there isn’t already a trusted signature available for the script.
• Validate the signature(s) after download, and provide a report (eg: valid/invalid).

• Offer to replace the signature (with yours) if it’s not a trusted x509 authenticode signature.

What certificate system should we use?

You may have assumed that we’re planning on using Microsoft’s code signing which is built into PowerShell, but when we were discussing this in the IRC channel, one of the things that kept coming up is that one way or another, we’re essentially creating an alternative way for people to “trust” the certificate — since we’re assuming that most of these certificates will be self-signed.

That is, if we use x509, we’ll STILL be creating an alternate way for people to say that they trust the x509 certs, and thus, using them in a way they weren’t intended. If we use PGP, we’ll basically be using them as intended, and will have peer key-signing as a trust mechanism, but we’re STILL introducing a secondary way for users to establish trust for PowerShell scripts which doesn’t integrate with the engine’s policy settings, thus making things more complicated.

Let me sum up the positive and negative sides of what I see as our two options.

x509 (aka “Authenticode”) signatures — supported by Microsoft.

• Probably self-signed and therefore won’t “work” properly in PowerShell anyway.
• Some of them would probably be commercial certificates issued by trusted CAs like Thawte or Comodo, giving you instant trust in the identity of the author. In that case, they would additionally be:
• Verifiable by PowerShell natively, and therefore, they:

• Don’t require a separate signature in order to execute when the ExecutePolicy is set to AllSigned.

PGP signatures (supported by the Open Source community and used in Debian, etc)

• Just as (un)trustworthy as any other self-signed certificate ... except that:
• PGP certificates (keys) are inherently user-signable. The community can vouch for each other’s identities, and create a web-of-trust for authentication purposes (which is all x509 really accomplishes anyway — you trust that Verisign makes sure that they are who they say they are, and live where they say they live).
• Not inherently usable by PowerShell.

• AllSigned mode requires re-signing (probably with a self-signed cert). This also means that if you have an x509 authenticode-signed script to submit, we would still need you to re-sign it with a PGP certificate when you wanted to upload it.

Final thoughts

Of course, there’s a lot of outstanding issues with this idea. But I wanted to put it out there for some broader feedback, particularly because we really are thinking about using PGP certificates since they can be counter-signed by other users, and since the general consensus opinion is that actually expecting scripters to buy code-signing certificates is just out of the question.

So the first question is, can we do PGP signing in pure .Net for a cmdlet (maybe using bouncy castle), and can we easily create a Set-PGPSignature cmdlet?

Has there been any progress on a way to do PGP signing that’s compatible with XML files (eg: ps1xml files)?

Can we do signature checking in-memory, so we can download the script with many signatures embedded and stitch them together for verification without creating multiple temporary files?

Regardless, if you trust a signature, but the signature isn’t Authenticode (PGP) or isn’t Valid (self-issued), the PowerShell security measures will require you (the end user) to sign the script in order to allow it to execute — essentially, every signed script on your system will be signed by you (or your sysadmin) and so, signing essentially becomes the administrator’s equivalent of blessing a script, and is somewhat like setting the eXecute flag on a linux script — except that you have to re-set it every time you edit the script.

We need to make signing slightly easier.

It’s a pain to find your certificate, and the built-in AuthenticodeSignature cmdlets are horrible at parsing parameters.

We need to make generating these self-signing certs trivial for non-SDK machines

It’s really pretty easy with MakeCert, but that’s not redistributable, and the Windows SDK is a ridiculously large download for someone who just wants to sign their scripts. I’ve written a script to generate code-signing certs using OpenSSL, which is redistributable, but it’s still not great.

PowerShell loads “machine” profile scripts (which are located in the PowerShell folder) and “user” profile scripts (located in your Documents\WindowsPowerShell folder). But there’s a little more to it than that: PowerShell is a scripting engine which can be hosted inside any app, PowerShell.exe is a DOS-style console which is the default host. There are several third-party hosts available such as PowerShell Plus and PowerGUI and several open source hosts such as BgShell and PoshConsole … in order to support this ecosystem of hosts, the default PowerShell behavior is to load a host-specific profile script (for both the machine settings and the local-user settings). Not all hosts will do that, but anyway … the default host loads Microsoft.PowerShell_profile.ps1 and Profile.ps1 from both the user and machine locations.

By default, none of those profiles actually exist. Once you’ve installed everything as in Part 1, you should have a Profile.ps1 file provided by PSCX. This profile defines a whole bunch of values that are used by various PSCX cmdlets and scripts, so you may want to change some of it, but you should be careful about just deleting things until you’re well acquainted with the PSCX cmdlets. Over time, I’ve added settings to my profile for other snapins as well, and there gets to be a lot of noise in there that’s specific to different snapins, so instead of just leaving all of that in my main profile, I rename the Profile.ps1 file provided by PSCX and then dot-source it from a new blank profile script.

In fact, and I found that I started collecting a lot of scripts in my WindowsPowerShell folder so I created a sub-folder for them, and I automatically load everything that’s in that folder, so I don’t have to manually dot-source things when I add a new snapin profile.

Authenticode Signing your auto-load scripts

In order to make sure that automatically loading scripts doesn’t become a way for people to attack my computer, I made a decision awhile ago that I would only auto-load signed scripts. The how and why of this is a bit much to get into, and I wrote about Generating Windows Authenticode Code-Signing Certificates with OpenSSL a while back, so you can read that if you want more details, I want to review the simplest steps.

Edit: I should take a moment here to point out, in case you’re really new to PowerShell, that the first thing you’ll have to do is fix the error “File … cannot be loaded because the execution of scripts is disabled on this system.” I originally was just assuming you would have figured that out — it tells you to read the about_signing help, so you can just execute get-help about_signing and it explains in there what you need to do. In case you haven’t gotten that far, before you can execute the New-CodeSigningCert you’re going to need to run PowerShell as administrator (“elevated”) and execute this command: Set-ExecutionPolicy RemoteSigned … that will let you execute most scripts that you have saved locally without having signed them. You may want to tighten that up later and set it to “AllSigned,” but first you have to be able to sign scripts.

Generating a code-signing certificate

Edit: I’ve simplified this a bit, and modified the script to import the certificate to the Current User certificate store if you aren’t running in an elevated console (in Vista) — which should work fine if you’re the only user on your machine that needs to run the scripts — if you need them in the Local Machine store, you need to be running as administrator. The script will let you know which it does, so you’ll know, one way or another.

Step 1. Download my PoshCerts package and unpack it in your WindowsPowerShell folder — lets say in, WindowsPowerShell\PoshCerts\bin.

Step 2. Run the New-CodeSigningCert script to generate into the Certs folder. So if you’re in the WindowsPowerShell directory, you can just run it and you’ll be prompted for a few pieces of information that the certificates require, plus two passwords — and all of the keys will be generated into the Certs folder as files, and imported to your local store. Make sure you make a note of those passwords.

Edit: I came up with a Step 3. Under most circumstances (that is, unless you were planning on running a corporate Certificate Authority), you’ll have no further use for the CA certificate, If you want to make sure that nobody can abuse your root CA … you can and should just delete the private certificates, like so: Remove-Item *Root-CA.* -exclude *.crt

Signing Scripts

You can now sign scripts at will using the pfx file generated in step 2 with the Get-PfxCertificate cmdlet, or the Cert: provider (you have use -ImportAll when you call New-CodeSigningCert, not just -Import — that causes the import of your code-signing certificate to the “My” store … then you can do Get-ChildItem "Cert:\CurrentUser\My\$thumbprint" where $thumbprint is your certificate’s thumbprint).

Let’s rename our Profile.ps1 script and then sign it. We’ll create create a folder called “AutoModules” to stick your PSCX profile (and any future such scripts) in. If you’re still on PowerShell 1, you’ll just put the .ps1 files into that folder, and we’ll dot-source them.

Edit: The simplest

Checking for valid signatures

Once you’ve got that set up, we need to create the new profile script and modify it to load not just the PSCX module, but any other signed scripts we put in there. Paste this into your new Profile.ps1, and don’t forget to sign it.

If you’re testing PowerShell 2, you’ll want to treat these scripts as Modules … SnapIns themselves can be loaded as modules in PowerShell 2, but so can any script which needs to be dot-sourced. In this case, the easiest thing is to create a subfolder for each one and then use Add-Module with the folder name. There are some problems with that, which I’ll go into in Part 3.

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