As you can see, in the case of a UNTRUSTED, but correct, signature, you get the UnknownError status. If you checked the output object, it has a StatusMessage which says “A certificate chain could not be built to a trusted root authority”. If the script has been altered (as in my SampleBAD.ps1 scripts) then the signature is incorrect, you get the HashMismatch status, and the corresponding StatusMessage is: “The contents of file SCRIPTS:\TrustedCert\SampleBAD.ps1 may have been tampered because the hash of the file does not match the hash stored in the digital signature. The script will not execute on the system…”

One odd thing is that the messages are inaccurate about not executing the script: if you have your execution policy set to Unrestricted, the signatures aren’t checked at all, and if you have it set to RemoteSigned they are only checked for remote scripts. Furthermore: if you do have your execution policy set to AllSigned, neither the UnknownError nor the HashMismatch script will execute — only the one Valid scripts will.

So what?

The bottom line is: you can verify that nothing has happened to the script — even if you don’t trust the person who signed it nor the person, group, or company that issued a certificate to them. Why does this matter? Well, I recently wrote a post about generating self-signed code-signing certificates which can be used for signing PowerShell scripts, and if you chose to distribute scripts signed with one of those certificates, nobody would be able to verify the root CA(Certificate Authority) and so the signatures would never come out as valid.

Is there any usefulness in this? Well, I guess that depends on your perspective, but basically, I think that if I published my scripts signed and tell you on my blog what my certificate thumbprint is … that you’d be more able to trust those scripts than you are now (when they’re not signed at all). Of course, I could go one step further, and publish my own self-signed root CA certificate so you could choose to trust that …

I was recently having a conversation about the future of the PowerShell Script Repository and it involved some discussion of whether it would be safe to use the Repository Scripts to download dependencies automatically… The answer, obviously, is no.

But it started me thinking again about scripts being signed. If you had already chosen to run a script provided by me (which was signed by a certificate you couldn’t verify), maybe you’d be willing to trust other scripts signed by the same certificate, so we could automatically download them. Well, maybe even then you wouldn’t want to trust it, but lets assume that you were running a copy of the PowerShell Script Repository internally at your company …

Would you use automatic dependency downloading?

We could easily have a function that takes the script name and verifies that you have that script available — and if not, it could fetch the script from your designated repository and verify that the signature is valid even if the certificate isn’t signed by a root certificate authority you trust.

Of course, such automatically downloaded scripts would need to be marked as “Remote” so if you had your Execution Policy set to AllSigned or Remote Signed, then the script would only run if you had trusted it’s author (and you wouldn’t even be offered the option if you hadn’t trusted the CA(Certificate Authority) that issued his script. In that case you would need to review the script and re-sign it yourself — or manually remove the “remote” bit.

Imagine something like this:

When you tried to execute Get-Paste, it would check for Get-Webfile, and if it couldn’t find it, would attempt to download it (presumably this would involve asking your permission, and placing it in some specific location that was in your PATH, so that the script could find it when it tried to execute it on the next line).

Or maybe, an Apt-Get?

Perhaps instead of this mechanism, we could use the new embeddable “Data Language” to provide a list of dependencies, like: DATA Dependencies { scripts = Get-WebFile } and run a Resolve-Dependencies function against each script before trying to execute it — this way, if you downloaded a script from the repository using Get-Paste, it could automatically Resolve-Dependencies and offer to download the other scripts at the same time.

The fact is that doing this correctly will require some major reworking of the script repository to allow tracking new versions of scripts better, and to let the script repository track dependencies explicitly so that you don’t have to download the whole script to find out what it’s dependencies are, but this could be done, if people are actually interested in it.

A web of trust?

Ad I’m thinking about this, I’m wondering again about the possibility of creating an informal web-of-trust style code-signing certificate tree. The idea would be that the Script Repository would have a CA certificate of it’s own, and would issue code-signing certificates to PowerShell developers cheaply (free?) by skipping over some of the usual verification steps. In an ideal world, Microsoft would issue the PowerShell Community a “SubCA” certificate signed by their root — in the interests of promoting code signing for PowerShell …

However, if we couldn’t get a SubCA certificate for “free” or cheap, we could simply generate and self-sign our own, and publish it on the Script Repository website, requiring users to download and import it into their trusted roots if they wanted to use trust permissions. Regardless of whether they chose to trust it or not, they could still verify the scripts were valid, which is better than what we have now — the rest would be up to the user.

Of course, if we were issuing certificates that were self-signed anyway, we could go a step further and sign SubCAs and distribute them to, say, the Microsoft PowerShell MVPs and trusted community leaders after verifying email addresses and physical mailing addresses etc … trusting them further to issue (less trusted) code-signing certificates to additional developers.

Call to action

All of this is extra work for the people maintaining the script repository web site (right now, that’s me), but it might be worth it if it makes it easier to use the script repository, easier to trust the scripts on it, and easier to verify that an author is who he says he is … what do you think?

1. Should we put in the work to set up a web of trust or should we leave it up to individual developers to self-sign and generate their certificates (and publish their public roots on their websites or something)?
2. Should we just leave it at that (scripters can sign their scripts if they feel like it), or should we push and promote script signing? As an incomplete example of promoting code-signing, I mean:
   1. We can use certificates as the primary (or only) way for authors to identify themselves (that is: no log-ins, unsigned scripts are marked “anonymous” ... but we track the thumbprints and allow you to browse scripts signed by the same author, etc).
   2. We can include the signature thumbprint with the short descriptions output on the search results and from the scripts which interact with repository.
1. We can restrict “latest version” updates to only scripts which are signed, and optionally to new versions signed by the same certificate.

1. Is there any point (or hope) in trying to get a signed CA certificate? Can Microsoft help us out? Do any of you work at a certificate authority?

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