vscode-powershell: Cannot run PowerShellEditorServices when execution policy is set to AllSigned

After workshopping a good way to trust the MS certificate (the obvious problem being that any PowerShell script to trust the certificate would also be untrusted), it turns out a very simple way is to just interactively import the editor services module and select Always run (verifying that the signing certificate is indeed a Microsoft Corporation one).

So:

ipmo ~/.vscode/ms-vscode.powershell*/modules/PowerShellEditorServices/PowerShellEditorServices.psd1

Then:

That worked, I left it at CurrentUser, since I’m the only user of this computer. No errors, and the integrated console loads without issue now as well.

I’ve looked into this a bit more (above script was a naive attempt to turn a GUI procedure into script).

Here’s a script that I’ve verified works on my machine:

# The signature for the EditorServices module file
$cert = (Get-AuthenticodeSignature ~\.vscode\extensions\ms-vscode.powershell*\modules\PowerShellEditorServices\PowerShellEditorServices.psd1).SignerCertificate
# Get the Cert:\CurrentUser\TrustedPublisher cert store
# IMPORTANT: You may not want CurrentUser here -- change to your needed location
$store = [System.Security.Cryptography.X509Certificates.X509Store]::new("TrustedPublisher", "CurrentUser")
# Open the store
$store.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::MaxAllowed)
# Add the cert to the TrustedPublishers store
$store.Add($cert)

I spoke with @TravisEz13 about this and confirmed that we are indeed signing correctly with the correct certificate.

The problem is that PowerShell trusts no signing certificate out of the box and you need to add the certificate to your trusted cert list yourself. This isn’t something we should ever do automatically, but we should ideally ship a script that will do it all when invoked.

Here’s an implementation:

# Temp file path to put the cert on
$certPath = Join-Path $env:TEMP powershelleditorservices.cer
# The signature for the EditorServices module file
$sig = Get-AuthenticodeSignature C:\Users\roholt\.vscode\extensions\ms-vscode.powershell*\modules\PowerShellEditorServices\PowerShellEditorServices.psd1
# Export the signing certificate to a file for import
$sig.SignerCertificate.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Cert) > $certPath
# Import the certificate into the machine's cert store
Import-Certificate -FilePath $certPath -CertStoreLocation Cert:\CurrentUser\TrustedPublisher

Hi @rjmholt,

I just tested this, and it seems to be working just fine now with the GPO set to AllSigned. No issues loading VS Code or the Powershell Extension at all. Intellisense and everything seems to be working as intended. (VS Code 1.28.0 and Powershell extension 1.9.0.)

Thank you for making that happen!

Thanks for the detailed explanation, everyone!

It sounds like we need to take one of two paths:

• Make sure that everyone who has VS Code has those root certs, possibly by including them with VS Code.
• Sign using an Issuer that everyone already has installed on their machine.

Did I miss something?

I’ve managed to get Visual Studio Code working under AllSigned.

I don’t know how it had not struck me earlier but as @rkeithhill said earlier everything that needs to be signed is signed. So we do Get-AuthenticodeSignature<full path>\Start-EditorServices.ps1 | select * and see this

SignerCertificate      : [Subject]
                           CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

                         [Issuer]
                           CN=Microsoft Code Signing PCA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

                         [Serial Number]
                           33000000C4E989F87A8150E9FF0000000000C4

                         [Not Before]
                           8/11/2017 11:20:24 PM

                         [Not After]
                           8/11/2018 11:20:24 PM

                         [Thumbprint]
                           9ACA9419E53D3C9E56396DD2335FF683A8B0B8F3

Microsoft Code Signing PCA 2011 is not on my machine’s Trusted Root Certification Authorities list. Googling Microsoft Code Signing PCA 2011 leads me to knowing that this certificate is distributed along with Visual Studio itself and the necessary file is name “manifestSignCertificates.p12”. There’s a mention in this guide that one needs to install a number of certificates for Visual Studio offline installation.

This article mentions being able to download Visual Studio installation files doing this vs_community.exe --layout C:\vs2017offline --lang en-US as I hadn’t managed to find the certificates anywhere else (maybe they’re here on github somewhere).

So I get out this “manifestSignCertificates.p12” and double-click it ‘nexting’ it to my Trusted Root CAs. But in order to launch scripts under either RemoteSigned or AllSigned you need to trust both a root CA and a certificate issuer so then when I manually start .\Start-EditorServices.ps1 I still get a warning that Microsoft is not a Trusted Issuer. But! If you hit [A] to always launch scripts signed by that issuer its certifcate gets into Cert:\CurrentUser\TrustedPublisher and the script runs just fine. So VS Code now works as expected.

And this whole situation leads me to citing myself:

I can also see this behaviour (bypass scripts not working under AllSigned Group Policy setting) to be by design (please correct me if I’m wrong here) because doesn’t it mean that there is essentially a security blackhole in the mere existance of Bypass policy? I’m don’t know if everyone is allowed to run powershell with Bypass Execpol but it that’s the case I’m not really sure there’s any sense in having all those different policies if anyone can just run it like that).

Sorry for a bit broken English.

Ran into some information that might be helpful for this.

1. When AuthorizationManager calls out to SecuritySupport to get the execution policy it iterates scopes until it gets to one that isn’t Undefined. The order it iterates is here. Unfortunately both policy scopes come before the Process scope, meaning we have no way of overriding this.

2. The message from the exception being thrown means an exception was that wasn’t expected.

3. The AuthorizatonManager calls host API’s when a file is considered remote. I know the entry script itself doesn’t show as remote, but maybe something else does.

My guess is the problem is with the PSES host, it’s possible the prompt handlers aren’t fully initialized by the time the AuthorizationManager tries to call them. I’m not able to look into this much further than that, but hopefully that helps.

The bigger problem is that even if this is just a host problem, and that gets fixed, using VSCode in all signed would be a pain.

It seems this is definitely the issue; at least for me. We were pushing out the execution policy through GPO. As a test, I have turned that off, and left my machine set at AllSigned, and it runs just fine. Guess I’ll be looking into pushing that out through a registry setting instead moving forward.

Thank you for all the help!

@tylerl0706 RE: PS Terminal. Yes, I observed that with Integrated and Native RE: Stable - Agreed. I keep both installed.

Let me know if you need additional info - though I see Insiders has been updated and the issue is resolved.

Cheers

@tmknight looks like the integrated terminal in VSCode (insiders) isn’t working at all in today’s daily build.

With the PowerShell extension disabled, if you open the integrated terminal like so:

The terminal flashes open and disappears.

This would explain why we are seeing the error you are getting.

My recommendation:

• always have vscode stable as well
• wait until vscode fixes this issue in insiders

The issue opened on them for this is here: https://github.com/Microsoft/vscode/issues/42516 … and they already have a fix committed 🎉