Installer fails due to missing digital signature on Powershell scripts, even if they're signed

[micamoita]

Hi,

I'm facing an issue with a setup project that contains 3 powershell scripts as custom actions.
Target machines now demands (for security policies), for all scripts, a valid digital signature.
Originally, these scripts were set as Run PowerShell inline script custom actions, so the weren't digitally signed (only project files were, and the setup itself), so the setup failed.
To work around the issue, I moved the 3 inline scripts into .ps1 files, and signed them. Then, I replaced the 3 custom actions with their Run PowerShell script file alternative, with the "Attached script" option.
However, the issue during setup is unchanged (install log follows):

Code: Select all

MSI (s) (D8:20) [14:53:43:635]: Invoking remote custom action. DLL: C:\windows\Installer\MSIFE51.tmp, Entrypoint: RunPowerShellFileScript
Dumping PowerShell invoke log ...
--> Found PowerShell path: C:\windows\system32\WindowsPowerShell\v1.0\powershell.exe
--> PowerShell Script Execution Result Code: 1
--> PowerShell Script Execution log: 
File C:\Users\UT11552\AppData\Local\Temp\pssFE9B.ps1 cannot be loaded. The 
file C:\Users\UT11552\AppData\Local\Temp\pssFE9B.ps1 is not digitally signed. 
You cannot run this script on the current system. For more information about 
running scripts and setting execution policy, see about_Execution_Policies at 
http://go.microsoft.com/fwlink/?LinkID=135170.
    + CategoryInfo          : SecurityError: (:) , ParentContainsErrorRecord 
   Exception
    + FullyQualifiedErrorId : UnauthorizedAccess
CustomAction PowerShellScriptFile_addrights returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 14:54:14: PowerShellScriptFile_addrights. Return value 3.

From what I read, I suppose that AI takes the script out of the attached signed files, and creates a temporary .ps1 file (C:\Users\UT11552\AppData\Local\Temp\pssFE9B.ps1 in the example), and tries to run this new file, which is not the one I signed, causing the issue. Can you confirm this behavior?

How can I solve this problem? I thought about setting my 2 .ps1 signed scripts as installed files, but the problem is that 2 of these scripts needs to be executed before Install Execution Stage, when no files were written yet.

Thank you, and best regards.

Michele

[Sorin]

Hello,

When using "Attached script" option, the setup package places your signed script files in %temp% folder, renaming them. In this process, the digital signature of the files gets invalidated indeed.

As a workaround, you should include the scripts in your package (just add them in "Files and Folders" page). And use the "Script from disk" option from your "Run PowerShell Scipt File" action. If necessary, you could add the scripts as temporary files and reference their properties in "File path" from "Script from disk".

Best regards,
Sorin

[micamoita]

Hi Sorin,

I understand this may solve the issue with the scripts' digital signature. However, this will prevent me from running the scripts during the initial setup stage (before "Files and Folders" are copied to the target machine), am I right? Is there a workaround for this hurdle, too?

Thanks,

Michele

[Sorin]

Hello,

Temporary Files are copied during the CostFinalize standard action, at the beginning of the setup and removed during the InstallFinalize standard action. Please take a look on our article regarding Temporary Files Operations in the Files and Folders Page

If you need the scripts to be ran before Cost Finalize, I would recommend running the signed scripts placed next to the package. You could use "SourceDir" (for MSI) or "SETUPEXEDIR" (for EXE) properties in the path. These properties are resolved at install time and point to the path of the MSI or EXE Setup.

You should configure your "Run PowerShell Script File" custom action in the following way:
- select "Script from disk" option and in the file path enter :

Code: Select all

[SourceDir]script_signed.ps1

Hope this helps,

Best regards,
Sorin

[micamoita]

Hi Sorin,

I followed your suggestion, adding my signed scripts as temporary files, and pointing to them with [TempFolder] inside the custom action properties.
Unfortunately, the result is almost unchanged: it seems like a temporary copy file is still created and executed instead of my signed one. Here's the piece of log:

Code: Select all

MSI (s) (94:D0) [15:17:08:359]: PROPERTY CHANGE: Adding CustomActionData property. Its value is 'Flags0PropertyC:\Users\TESTUSER\AppData\Local\Temp\powershell_addrights.ps1'.

Action ended 15:17:08: AI_DATA_SETTER_6. Return value 1.

MSI (s) (94:D0) [15:17:08:359]: Doing action: PowerShellScriptFile_addrights

Action start 15:17:08: PowerShellScriptFile_addrights.

MSI (s) (94:D0) [15:17:08:359]: Note: 1: 2262 2: CustomAction 3: -2147287038 

MSI (s) (94:D0) [15:17:08:359]: Transforming table CustomAction.


MSI (s) (94:D0) [15:17:08:359]: Note: 1: 2262 2: Binary 3: -2147287038 

MSI (s) (94:D0) [15:17:08:374]: Transforming table Binary.


MSI (s) (94:40) [15:17:08:374]: Invoking remote custom action. DLL: C:\windows\Installer\MSI8848.tmp, Entrypoint: RunPowerShellFileScript

Dumping PowerShell invoke log ...

--> Found PowerShell path: C:\windows\system32\WindowsPowerShell\v1.0\powershell.exe

--> PowerShell Script Execution Result Code: 1

--> PowerShell Script Execution log: 
File C:\Users\TESTUSER\AppData\Local\Temp\pss8891.ps1 cannot be loaded. The 

file C:\Users\TESTUSER\AppData\Local\Temp\pss8891.ps1 is not digitally signed. 

You cannot run this script on the current system. For more information about 

running scripts and setting execution policy, see about_Execution_Policies at 

http://go.microsoft.com/fwlink/?LinkID=135170.

    + CategoryInfo          : SecurityError: (:) , ParentContainsErrorRecord 

   Exception

    + FullyQualifiedErrorId : UnauthorizedAccess

CustomAction PowerShellScriptFile_addrights returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)

Action ended 15:17:24: PowerShellScriptFile_addrights. Return value 3.

As you can see in the first line, my script file is correctly referenced, but when the error occurs, the .ps1 file is another one (pss8891.ps1).

What are we missing?

Thanks

Michele

[Sorin]

Hello Michele,

Unfortunately, the result is almost unchanged: it seems like a temporary copy file is still created and executed instead of my signed one.

I'm sorry for my misleading previous suggestion. It seems that this behaviour is also encountered for "Script from disk" option of "Run PowerShell Script File" action.

As you can see in the first line, my script file is correctly referenced, but when the error occurs, the .ps1 file is another one (pss8891.ps1).

This is indeed our standard behaviour. After discussing with the development team, I can explain this behaviour.

If using the "Run PowerShell script file" custom action, Advanced Installer parses the signed script and creates a new script file, in your case "pss8891.ps1". This is because of our custom support for get / set properties via PowerShell scripts. Basically this new script is generated by parsing the old script and replacing our custom get / set property commands with custom functionality written by us. In this process the digital signature of the file gets invalidated.
You could find more details regarding our support for get/set properties in power shell scripts here: Run Inline Windows PowerShell Script.

The only workaround to this issue is to use another type of custom action for launching the signed PowerShell script. You could use for example a "Launch file" Custom action configured as it is described in the screenshot attached. This custom action is configured for launching "script_signed.ps1" file that was previously added as a temporary file to the project. Please keep in mind that if you are using this workaround, you cannot get or set installer properties in you scripts.

Best regards,
Sorin

[Catalin]

Hello,

This improvement has been implemented in Advanced Installer 17.1, released on May 27th, 2020.

Best regards,
Catalin