Author Posts

January 14, 2016 at 9:55 am

We got a code signing certificate from entrust specifically for signing powershell scripts. I'm not having any problem signing the scripts at all. The issue we are having is any time we try to run one of the signed scripts on any PC that's security is set to 'AllSigned' we get the following warning Message:

Do you want to run software from this untrusted publisher?
File J:\Signing.ps1 is published by CN=OurCompany, O=OurCompany, L=OurTown S=OurState, C=US and is not trusted on your system. Only run scripts
from trusted publishers.
[V] Never run [D] Do not run [R] Run once [A] Always run [?] Help (default is "D"):

Sure you can choose '[A] Always run' and it will install the public key for the cert into the users store but that was the whole purpose of getting a code signing cert from a CA rather than just using a self signed cert. Any idea whats going on here?

January 14, 2016 at 9:57 am

The problem is that the computer doesn't trust the CA. You need to install the CA root Cert as a trusted root publisher.

January 14, 2016 at 10:31 am

This particular prompt means that the code-signing certificate hasn't been added to the Trusted Publishers store yet. When you click "Always Run", that's what happens behind the scenes. This extra layer of security means that your computer won't just run any old script (which could potentially be malware, even if it's signed) unless you've explicitly said that you trust that particular publisher.

If you're in an Active Directory environment, the simplest thing would be to push out your code-signing certificate as a Trusted Publisher with Group Policy: https://technet.microsoft.com/en-us/library/cc770315%28WS.10%29

January 14, 2016 at 1:39 pm

Thanks a lot. I was actually on the phone with entrust and they couldn't figure it out either. They checked my machine where i was trying to run the script and i had the root CA in my trusted root certificate store.

That being said purchasing a coding signing cert for just signing powershell scripts is probably a waist of money. In the end if you use a self-signed cert of one from a CA you will have to do the same thing. Deploy certs using GP. Why not just create a self-signed cert and set the expiration date to well in the future so you don't have to mess with it every 3 years.

At first i didn't understand this "extra" security measure but thinking about it makes sense now. Would you want to trust any scripts created by any company in the world that has obtained a code signing certificate from a CA (for example i have the Hong Kong Post Office in my cert store as a CA). Most likely not!! Unfortunately that makes obtaining a official coding signing cert from a CA next to useless.

In the end the support rep from entrust thanked me and told me learned something new today and would pass this info to the rest of his support team.

January 14, 2016 at 1:43 pm

Yep. In an enterprise environment, you've got total control over what CAs and publishers your clients trust, so there's very little advantage to purchasing a certificate for internal use. You might not necessarily go with the self-signed certificate route (it's a good idea to have some sort of enterprise PKI anyway), but it doesn't have to come from an external CA. (If you were going to sign code and allow people to download it outside your company, though, that would be a different matter.)

January 15, 2016 at 11:21 am

did you check the certificate chain? frequently windows will have the CA's in it's trusted list but not the intermediary. so even if you purchased a trusted CA signed cert, it's not trusted without the chain linking it back to the trusted CA.

With a website you have to place both the cert and the intermediary cert together. I'm not sure how to do it with powershell signing. part of the reason I stick to using our internal CA, as AD published both the root and intermediary to every machine.