Set-AuthenticodeSignature fails on scripts created from ISE - by clarkalindsey

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 483431 Comments
Status Closed Workarounds
Type Bug Repros 27
Opened 8/17/2009 7:06:49 PM
Access Restriction Public


When you use the ISE to create a ps1, the default encoding is 'Unicode big endian'.

Then Set-AuthenticodeSignature returns
Status                 : UnknownError
StatusMessage          : The data is invalid
Path                   : C:\temp\Test-ScriptEncoding.ps1

Use notepad.exe to save the file as UTF-8 and the command returns 
Status                 : Valid
StatusMessage          : Signature verified.
Path                   : C:\temp\Test-ScriptEncoding.ps1



Sign in to post a comment.
Posted by Always_Learning on 3/10/2015 at 8:54 PM
@Self: I've just confirmed my suspicion about the lack of a Private Key.

When getting a certificate using Get-ChildItem:
$cert=Get-ChildItem -Path cert:\CurrentUser\my -CodeSigningCert
$cert | select PrivateKey

When getting a certificate using Get-PfxCertificate:
$cert=Get-PfxCertificate .\myCertificate.pfx
#Enter password
$cert | select PrivateKey

Notice that the first PrivateKey is empty/null.
Posted by Always_Learning on 3/10/2015 at 8:19 PM
Argh, talk about a waste of time... more helpful error messages would be helpful Microsoft!

According to "help Set-AuthenticodeSignature -examples" this should work:
$cert=Get-ChildItem -Path cert:\CurrentUser\my -CodeSigningCert
Set-AuthenticodeSignature -FilePath someScript.ps1 -certificate $cert -IncludeChain All -TimeStampServer $timeStampServer

Doing a "Write-Host $cert" certainly shows the correct certificate has been returned, but as with other people here I was getting the dreaded "UnknownError" regardless of whether the .ps1 script was saved in ANSI, UTF-8 or Unicode formats.

In the end I finally got it to work by loading the .pfx file directly, as per the second example:
$cert=Get-PfxCertificate .\myCertificate.pfx
Set-AuthenticodeSignature -Filepath ServerProps.ps1 -Cert $cert -IncludeChain All -TimeStampServer $timeStampServer

My suspicion is that because Get-ChildItem doesn't prompt for the certificate's password it's only getting the Public Key portion and not the Private Key portion actually needed to sign the script. Hope this helps!
Posted by Ab Ye on 3/26/2014 at 8:17 AM
This workaround works on windows 7 but does not work on Windows Server 2012 ...

On Windows Server 2012
- I've saved the ps1 file in utf-8 format
- Opened the file in ISE and saved using "$psISE.CurrentFile.Save([Text.Encoding]::UTF8)"
- Saved the file using the command -- type "file1.ps1" | out-file "File2.ps1" -encoding utf8

Always get Status = "UnknownError".
Also attempted with a Copy of the file authenticated on Windows 7 with the same certificates installed on the server, that doesn't work either. I get the error ... " because the hash of the file does not match the hash stored in the digital signature"

Has this workaround worked for anyone on Windows Server 2012?
Posted by John Kavanagh on 2/8/2014 at 6:38 AM
This is marked as fixed?
Posted by danloughney on 3/22/2013 at 5:23 AM
Completely agree with uSlackr. Until I found this post, I had no idea why some of my scripts would sign and others would not. Turns out I was seeing my scripts written in VS vs. those written in ISE. My workaround was set-executionPolicy Unrestricted and that was just no good.
Posted by kestasjk2 on 5/28/2012 at 12:40 AM
I also agree with uSlackr..
Posted by Eduardo Walker on 1/2/2012 at 1:34 PM
I tell you I have to agree with the comment from "uSlackr"!!
Posted by Shawn Eary on 10/22/2010 at 7:16 PM
This also happens in the PowerShell ISE 2.0 Host Build Number 6.1.7600.16385 on Win 7 Ultimate 64 Bit. The "UnknownError" Status code is a really bad error message for this problem.
Posted by Aaron Hope on 5/24/2010 at 7:50 AM
Though a workaround exists and is easily discoverable, this is still well worth fixing.
Posted by Henry Gabryjelski - MSFT on 2/23/2010 at 2:14 PM
Ouch. I spent days trying to figure out this obscure error. That's not good.
Posted by gallwapa on 1/25/2010 at 8:36 AM
I can confirm this problem is an issue for us as well. The workaround does fix it.
Posted by uSlackr on 12/16/2009 at 6:20 AM
Dear MS, let me lay out a case for getting this fixed
As powershell was developed and deployed, MS took great care to make it secure by default. Most of the resources I've read encouraged secure coding practice by pushing scripterds to sign their code rather then turn down the security level. This is good stuff. With the introduction of this error, there is now a big barrier to entry (due to the lack of information on the internet and the obscurity of the error message.)

In order to maintain the security mindset of the powershell ecosystem, I challenge you to fix this quickly (and certainly before the internet anti-MS trolls pick up on this)