I am trying to update Powershell to version 5.1 which I have downloaded directly from Microsoft's website. The download's are signed from Microsoft (although the signatures are expired by a few months), but when I try to run the script I am given an error saying that this script is not trusted by my computer, and if I should continue to execute the script?

I am wondering why a script, directly from Microsoft's website, would present an error as being "unsafe." I am curious if people would recommend me to NOT run the script, or how I should proceed since I have to update to Powershell 5.0+ in order to configure another application (yeah very annoying).

Also to note that there were 2 different pages on Microsoft's site where I could download these scripts and each page had a different download link from the other. One was from download.microsoft and the other was from go.microsoft (I downloaded from the former link). I am not sure why there are 2 different links, but not sure if that is a cause for concern.

https://docs.microsoft.com/en-us/powershell/scripting/setup/installing-windows-powershell?view=powershell-6 (this is the page where I downloaded my script)

I can't seem to find the other page with download information though, but this other page also had information on how to upgrade powershell. The page said to run the script from the powershell console(didn't work for me so I right click and clicked "execute script"). The first link (above) doesn't give any information on what we should do to upgrade. I have not tried running the MSU file itself either.

Here is some safety information on the 2 files that were downloaded in a zip file from the first link.

https://whitelisting.kaspersky.com/advisor#search/e3142d5fada08ea6a1ba2134e4015a5c (ps1 file)

https://whitelisting.kaspersky.com/advisor#search/cef5ecbdf9b396fcab5bd73e5c6cb4bf (msu file)

The first is signed by "Microsoft Code Signing PCA 2011" and the second is signed by "Microsoft Code Signing PCA" not sure that means anything though. I find it odd that the signing is expired as well and hasn't been updated.

I am wondering if maybe the signature being expired has something to do with this "untrusted" issue or maybe there is something deeper than that?

EDIT: This is what is says when I run the script.

"Do you want to run software from this untrusted publisher?

File (name) is published by CN=Microsoft Corporation, OU=MOPR, O=Microsoft Corporation, L=Redmond, S=Washington, C=US and is not trusted on your system. Only run scripts from trusted publishers."

then asks if I want to run it.

Thank you all for any help on this matter.

  • does it claim it's unsafe, or just mechanically untrusted? huge diff.
    – dandavis
    Commented Aug 10, 2018 at 19:48
  • @dandavis I edited the main post with the information.
    – MXBuster
    Commented Aug 12, 2018 at 0:08

2 Answers 2


An expired signature should always trigger a warning for signed code, whether it is compiled or interpreted. This is normal and expected.

On top of that, the CA cert used to sign that cert is also expired.

Since the file came directly from the vendor, it is probably safe to use. This is especially true since it was countersigned by their time stamp PCA, which acts as a witness that this file existed at the date specified and was already signed by Microsoft at that point. (Countersignatures are usually done by third parties, but whatever.)

While it is bad form to distribute code signed with expired certs, it is not unheard of. In this case, the signer and the distributor are the same company, so they could simply cease distribution if they believed the file was altered.

Overall, this is bad form, but it is not terribly surprising.

  • Thanks for this. I figured it was weird that the file wasn't updated, and I wonder if the other page I was looking at could be an updated version, but I cannot find that page anymore (even in my history) and the other page comes up in a quick web-search. I figured that since it's from Microsoft that I should be okay, but wanted to double-check. The whitelist scans show that it's safe and signed (even with the expired certs), but I'm not sure how accurate it is with detecting malicious code. So you yourself would run this script then? Thanks!
    – MXBuster
    Commented Aug 9, 2018 at 23:34

I had this same question recently; I learned and reminded myself that:

  • There's almost always going to be some risk.

  • Powershell does use great security technology to provide assurances against known avenues that have been abused in the past.

  • Knowing the technology and what Powershell is actually doing is helpful.

  • Just because a file was transported directly from Microsoft's servers over a secure channel on the internet doesn't mean a file could not have been modified before or after being transported.

  • Digital File Signatures provide for authenticity and integrity, so you can know that it was indeed from Microsoft (before being transported to your machine) and hasn't been modified since then.

  • It's completely normal/expected to have a file created some time ago signed with a certificate that's since expired.

  • This prompt is really just asking if you trust that entity, before you turn your computer over to a script they wrote and hasn't been modified by anyone else since.

  • If the certificate or timestamp weren't valid you would not be seeing this prompt.

  • You can manually/independently review these. (Not just the certificates in an instance like this, but create your own certificates and sign your own files. See what happens in different scenarios. Independent verification is a trust factor.)

  • There's no inherent/built-in trust with a strict execution policy in force, the user has to consent to hence become accountable (versus blaming the platform if something goes wrong).

  • These are all welcome improvements over past unrestricted abilities.

Microsoft Powershell Docs, state that:

The execution policy isn't a security system that restricts user actions. For example, users can easily bypass a policy by typing the script contents at the command line when they cannot run a script. Instead, the execution policy helps users to set basic rules and prevents them from violating them unintentionally.

Another doc says:

The digital signature in a script is valid until the signing certificate expires or as long as a timestamp server can verify that the script was signed while the signing certificate was valid.

Because most signing certificates are valid for one year only, using a time stamp server ensures that users can use your script for many years to come.

So some important things can actually be trusted with what was going on in that scenario.

Can you trust there wasn't a bug in that script? Well, hopefully time will have told you that. The industry doesn't have a solution to give complete trust over things like that ahead of time.

However, with a strict execution policy like that owners and developers would be better able to tell what a hypothetical problem was caused by. This also means it's likely to prevent some kinds of accidental runs of desperate users. Ultimately, that means better experiences.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .