vscode-powershell
vscode-powershell copied to clipboard
PowerShell
v2024.2.0: PowerShell Terminal Fails to Load Due to PSES change to non-Windows-trusted Certificate
Prerequisites
- [X] I have written a descriptive issue title.
- [X] I have searched all open and closed issues to ensure it has not already been reported.
- [X] I have read the troubleshooting guide.
- [X] I am sure this issue is with the extension itself and does not reproduce in a standalone PowerShell instance.
- [X] I have verified that I am using the latest version of Visual Studio Code and the PowerShell extension.
- [x] If this is a security issue, I have read the security issue reporting guidance.
Summary
Hello, Since the extension updated itself to V 2024.2.0, I can't use the integrated Powershell terminal of my VS Code anymore, it won't load. My ExecutionPolicy is set by GPO to AllSigned : it has always been like that, it worked like that, and it's not planned to change. It's like the code in PSReadLine.format.ps1xml is now signed using an unapproved certificate on my side, or it tries desperately to force the ExecutionPolicy to change, which it did not do before.
When I finally kill the terminal, here's the output :
[Error - 8:47:47 AM] Microsoft.PowerShell.EditorServices.Services.PowerShell.Host.PsesInternalHost: Unable to load PSReadLine. Will fall back to legacy readline implementation. - System.Management.Automation.CmdletInvocationException: Des erreurs se sont produites lors du chargement du fichier de données de format :
C:\Users\XXX\.vscode\extensions\ms-vscode.powershell-2024.2.0\modules\PSReadLine\2.4.0\PSReadLine.format.ps1xml, , C:\Users\XXX\.vscode\extensions\ms-vscode.powershell-2024.2.0\modules\PSReadLine\2.4.0\PSReadLine.format.ps1xml : le fichier a été ignoré en raison de l’exception de validation suivante : Impossible de charger le fichier C:\Users\XXX\.vscode\extensions\ms-vscode.powershell-2024.2.0\modules\PSReadLine\2.4.0\PSReadLine.format.ps1xml. Une chaîne de certificats a été traitée mais s’est terminée par un certificat racine qui n’est pas approuvé par le fournisseur d’approbation..
---> System.Management.Automation.RuntimeException: Des erreurs se sont produites lors du chargement du fichier de données de format :
C:\Users\XXX\.vscode\extensions\ms-vscode.powershell-2024.2.0\modules\PSReadLine\2.4.0\PSReadLine.format.ps1xml, , C:\Users\XXX\.vscode\extensions\ms-vscode.powershell-2024.2.0\modules\PSReadLine\2.4.0\PSReadLine.format.ps1xml : le fichier a été ignoré en raison de l’exception de validation suivante : Impossible de charger le fichier C:\Users\XXX\.vscode\extensions\ms-vscode.powershell-2024.2.0\modules\PSReadLine\2.4.0\PSReadLine.format.ps1xml. Une chaîne de certificats a été traitée mais s’est terminée par un certificat racine qui n’est pas approuvé par le fournisseur d’approbation..
à System.Management.Automation.Runspaces.InitialSessionState.ThrowTypeOrFormatErrors(String resourceString, String errorMsg, String errorId)
à System.Management.Automation.Runspaces.InitialSessionState.UpdateFormats(ExecutionContext context, Boolean update)
à System.Management.Automation.Runspaces.InitialSessionState.Bind_UpdateFormats(ExecutionContext context, Boolean updateOnly)
à System.Management.Automation.Runspaces.InitialSessionState.Bind(ExecutionContext context, Boolean updateOnly, PSModuleInfo module, Boolean noClobber, Boolean local)
à System.Management.Automation.Runspaces.InitialSessionState.Bind(ExecutionContext context, Boolean updateOnly)
à Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadModuleManifest(String moduleManifestPath, ExternalScriptInfo manifestScriptInfo, Hashtable data, Hashtable localizedData, ManifestProcessingFlags manifestProcessingFlags, Version minimumVersion, Version maximumVersion, Version requiredVersion, Nullable`1 requiredModuleGuid, ImportModuleOptions& options, Boolean& containedErrors)
--- Fin de la trace de la pile d'exception interne ---
à System.Management.Automation.Runspaces.PipelineBase.Invoke(IEnumerable input)
à System.Management.Automation.PowerShell.Worker.ConstructPipelineAndDoWork(Runspace rs, Boolean performSyncInvoke)
à System.Management.Automation.PowerShell.Worker.CreateRunspaceIfNeededAndDoWork(Runspace rsToUse, Boolean isSync)
à System.Management.Automation.PowerShell.CoreInvokeHelper[TInput,TOutput](PSDataCollection`1 input, PSDataCollection`1 output, PSInvocationSettings settings)
à System.Management.Automation.PowerShell.CoreInvoke[TInput,TOutput](PSDataCollection`1 input, PSDataCollection`1 output, PSInvocationSettings settings)
à System.Management.Automation.PowerShell.Invoke(IEnumerable input, PSInvocationSettings settings)
à Microsoft.PowerShell.EditorServices.Services.PowerShell.Utility.PowerShellExtensions.InvokeAndClear(PowerShell pwsh, PSInvocationSettings invocationSettings)
à Microsoft.PowerShell.EditorServices.Services.PowerShell.Console.PSReadLineProxy.LoadAndCreate(ILoggerFactory loggerFactory, String bundledModulePath, PowerShell pwsh)
à Microsoft.PowerShell.EditorServices.Services.PowerShell.Host.PsesInternalHost.TryLoadPSReadLine(PowerShell pwsh, EngineIntrinsics engineIntrinsics, IReadLine& psrlReadLine) |
[Error - 8:47:47 AM] Microsoft.PowerShell.EditorServices.Services.PowerShell.Host.PsesInternalHost: Error occurred calling 'Set-ExecutionPolicy -Scope Process -ExecutionPolicy Unrestricted -Force' - System.Management.Automation.CmdletInvocationException: Windows PowerShell a correctement mis à jour votre stratégie d’exécution, mais ce paramétrage est remplacé par une stratégie définie dans un contexte plus spécifique. Votre environnement va donc conserver sa stratégie d’exécution actuelle, AllSigned. Tapez « Get-ExecutionPolicy -List » pour afficher les paramètres de stratégie d’exécution. Pour plus d’informations, voir « Get-Help Set-ExecutionPolicy ». ---> System.Security.SecurityException: Erreur de sécurité.
à System.Management.Automation.MshCommandRuntime.ThrowTerminatingError(ErrorRecord errorRecord)
--- Fin de la trace de la pile d'exception interne ---
à System.Management.Automation.Runspaces.PipelineBase.Invoke(IEnumerable input)
à System.Management.Automation.PowerShell.Worker.ConstructPipelineAndDoWork(Runspace rs, Boolean performSyncInvoke)
à System.Management.Automation.PowerShell.Worker.CreateRunspaceIfNeededAndDoWork(Runspace rsToUse, Boolean isSync)
à System.Management.Automation.PowerShell.CoreInvokeHelper[TInput,TOutput](PSDataCollection`1 input, PSDataCollection`1 output, PSInvocationSettings settings)
à System.Management.Automation.PowerShell.CoreInvoke[TInput,TOutput](PSDataCollection`1 input, PSDataCollection`1 output, PSInvocationSettings settings)
à System.Management.Automation.PowerShell.Invoke(IEnumerable input, PSInvocationSettings settings)
à Microsoft.PowerShell.EditorServices.Services.PowerShell.Utility.PowerShellExtensions.InvokeAndClear(PowerShell pwsh, PSInvocationSettings invocationSettings)
à Microsoft.PowerShell.EditorServices.Services.PowerShell.Utility.PowerShellExtensions.SetCorrectExecutionPolicy(PowerShell pwsh, ILogger logger) | Policy='Unrestricted'
[Warn - 8:52:46 AM] OmniSharp.Extensions.LanguageServer.Server.LspServerOutputFilter: Tried to send request or notification before initialization was completed and will be sent later OmniSharp.Extensions.JsonRpc.RequestCancelled | @Request='OmniSharp.Extensions.JsonRpc.RequestCancelled'
[Error - 10:48:27 AM] Server initialization failed.
Message: Pending response rejected since connection got disposed
Code: -32097
[Error - 10:48:27 AM] Connection to PowerShell Editor Services (the Extension Terminal) was closed. See below prompt to restart!
[Error - 10:48:27 AM] PowerShell Editor Services Client client: couldn't create connection to server.
Message: Pending response rejected since connection got disposed
Code: -32097
I rolled back to version 2024.0.0 and it works again.
PowerShell Version
Name Value
---- -----
PSVersion 5.1.19041.4170
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.19041.4170
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Name : ConsoleHost
Version : 5.1.19041.4170
InstanceId : 86e284ae-6000-426e-aa83-129c82a8b98b
UI : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture : fr-FR
CurrentUICulture : fr-FR
PrivateData : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
DebuggerEnabled : True
IsRunspacePushed : False
Runspace : System.Management.Automation.Runspaces.LocalRunspace
Visual Studio Code Version
1.88.1
e170252f762678dec6ca2cc69aba1570769a5d39
x64
Extension Version
[email protected]
Steps to Reproduce
- Open VS Code and wait for the Integrated Powershell Terminal to load and wait for prompt
- It never happens and stays like
PowerShell Extension v2024.2.0
Copyright (c) Microsoft Corporation.
https://aka.ms/vscode-powershell
Type 'help' to get help.
- Kill the terminal to see the output
Visuals
No response
Logs
No response
Since 2024.2.0 some components (DLLs and PS1/PSM1/PSD1) of the module are signed with a untrusted certificate/CA called "ameroot" - here is the output with sigcheck from Sysinternals, also affects AppLocker if you use application allowlisting:
Signers: Microsoft Azure Code Sign Cert Status: The revocation status of the certificate or one of the certificates in the certificate chain is unknown., Error 65536 (0x10000), The revocation status of the certificate or one of the certificates in the certificate chain is either offline or stale. Valid Usage: 1.3.6.1.4.1.311.91.1.1, Code Signing Cert Issuer: AME CS CA 01 Serial Number: 36 00 00 01 DF 73 81 97 16 BE 32 FD 0D 00 02 00 00 01 DF Thumbprint: 1226440E939A24EB202C2A517CE13F8326EFDE60 Algorithm: sha256RSA Valid from: 03:33 20.01.2024 Valid to: 03:33 19.01.2025 AME CS CA 01 Cert Status: The certificate or certificate chain is based on an untrusted root., The revocation status of the certificate or one of the certificates in the certificate chain is unknown., The revocation status of the certificate or one of the certificates in the certificate chain is either offline or stale. Valid Usage: KDC Auth, Server Auth, Client Auth, Enrollment Agent, 1.3.6.1.4.1.311.21.6, Document Signing, 1.3.6.1.4.1.311.21.6, OCSP Signing, IPSEC IKE Intermediate, DNS Server, EFS Recovery, EFS, Private Key Archival, Smartcard Logon, 1.3.6.1.4.1.311.20.2.3, Code Signing, 1.3.6.1.4.1.311.91.1.1, 1.3.6.1.4.1.311.91.2.1, 1.3.6.1.4.1.311.91.3.1, 1.3.6.1.4.1.311.91.5.1, 1.3.6.1.4.1.311.91.4.1, 1.3.6.1.4.1.311.91.4.2 Cert Issuer: ameroot Serial Number: 1F 00 00 00 51 EA 8F F6 9C 73 0C A8 3B 00 00 00 00 00 51 Thumbprint: E3981E455AAFF0C851FF1D3C4EF41EE6A4C087F5 Algorithm: sha256RSA Valid from: 20:44 21.05.2021 Valid to: 20:54 21.05.2026 ameroot Cert Status: The certificate or certificate chain is based on an untrusted root. Valid Usage: All Cert Issuer: ameroot Serial Number: 25 DA CB 55 C9 C6 77 81 40 9E 56 94 82 DE 4D FE Thumbprint: 413E8AAC6049924B178BA636CBAF3963CCB963CD Algorithm: sha256RSA Valid from: 00:52 25.05.2016 Valid to: 00:57 25.05.2026
Please MS fix this asap and sign this components with a trusted root CA - workaround is now to revert to V2024.0.0 - even the newer prerelease version has the problem with untrusted CA
No certificates are trusted on your machine by default. They are signed with updated certificates, you will need to trust those when running AllSigned.
See more info here: https://github.com/PowerShell/vscode-powershell/issues/3741#issuecomment-1036475665
This issue has been labeled as resolved, please verify the provided fix (or other reason).
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
No certificates are trusted on your machine by default. They are signed with updated certificates, you will need to trust those when running AllSigned.
That's not true - there is a list of Trusted root certificates which gets updated by Microsoft and Windows does download them automatically.
That Root certificate ameroot is not an official root certificate - so you have problems with AppLocker.
Issue is not resolved.
No certificates are trusted on your machine by default. They are signed with updated certificates, you will need to trust those when running AllSigned.
That's not true - there is a list of Trusted root certificates which gets updated by Microsoft and Windows does download them automatically.
That Root certificate ameroot is not an official root certificate - so you have problems with AppLocker.
Issue is not resolved.
Couldn't agree more.
This issue has been labeled as resolved, please verify the provided fix (or other reason).
This issue has been labeled as resolved, please verify the provided fix (or other reason).
Not resolved yet
This issue has been labeled as resolved, please verify the provided fix (or other reason).
@andyleejordan I can reproduce this on a clean Win11 box, though it's just silently failing for me with allsigned on even with all the verbosity turned on. The signing cert for PSES changed with the latest release, and it's not one that's trusted by Windows by default. Does this have to do with the build changes you made perhaps?
Ahh well that was embarassing. There was a typo in our pipeline that lead to a silent failure to use the correct certificate, so it defaulted to "Microsoft Azure Code Sign" instead of what it was supposed to be set to, "Microsoft Corporation." And that only shows up as a problem in particular circumstances (as you all have found). Hotfix release is on its way with this resolved. Thanks @JustinGrote for pointing that out. https://github.com/PowerShell/vscode-powershell/pull/4977
This issue has been labeled as resolved, please verify the provided fix (or other reason).
This issue has been labeled as resolved, please verify the provided fix (or other reason).
This issue has been labeled as resolved, please verify the provided fix (or other reason).
Confirmed fixed with v2024.2.1 and AllSigned on. Big thanks to everyone who helped resolve the issue.
@cyrkin thank you for persisting with additional information beyond our initial recommendation! Otherwise we wouldn't have caught it.
Exactly. There have been recurring issues with AllSigned in the past, so it took some extra digging to figure out what happened here. The specified key was right...the field was mistyped/copied as signing_environment instead of signing_profile and then just silently defaulted to the wrong key. Oh YAML.
Thanks, working nearly perfect except one DLL: AppLocker is still having a problem with the certificate(s) and counter signing of this file here:
.vscode\extensions\ms-vscode.powershell-2024.2.1\modules\powershelleditorservices\bin\common\System.Reactive.dll
The DLL "System.Reactive.dll" is counter signed from yesterday with a "Microsoft 3rd Party Application Component" certificate, but also still countersigned from the past in 2023 with the signer "Reactive Extensions for .NET (.NET Foundation)", which worked perfect in the previous version 2024.0.0 - could you please investigate this and sign it with only one certificate/counter signing? It's important to allowlist this DLL with publisher rule in AppLocker - thanks in advance.
I noticed that when setting this up actually, and unfortunately the System.Reactive.dll that's being restored from NuGet (version 6.0.0) is not first-party signed by "Microsoft Corporation" but by "Reactive Extensions for .NET (.NET Foundation)" so I have to dual-sign it as "Microsoft 3rd Party Application Component".
I see, but could the security engineers at Microsoft take a look because of AppLocker Application Allowlisting? Because with this new counter signed DLL a publisher rule doesn't work anymore, with the System.Reactive.dll from V2024.0.0 it works perfect - and all the other DLLs from the new V2024.2.1 work perfect with publisher rules, too. Thanks in advance, would be very happy when this issue could be resolved, security is very important for us ☺️
@andyleejordan is the Reactive DLL a direct dependency or something transitive from csharp-language-server?
Also, doing a sigcheck looks like the DLL itself hasn't changed in PSES from 2024.2.0 from 2024.3.2, so was this just a new detection that was a previous mis-signing?
As an aside, I found the reference to System.Reactive which @TylerLeonhardt added 4 years ago
C:\Users\JGrote\Projects\PowerShellEditorServices\test\PowerShellEditorServices.Test.E2E\Processes\ServerProcess.cs
While we could unwind that, It is also referenced in OmniSharp.Extensions.JsonRPC as a transitive dependency
"OmniSharp.Extensions.JsonRpc": {
"type": "Transitive",
"resolved": "0.19.9",
"contentHash": "utFvrx9OYXhCS5rnfWAVeedJCrucuDLAOrKXjohf/NOjG9FFVbcp+hLqj9Ng+AxoADRD+rSJYHfBOeqGl5zW0A==",
"dependencies": {
"MediatR": "8.1.0",
"Microsoft.Extensions.DependencyInjection": "6.0.1",
"Microsoft.Extensions.Logging": "6.0.0",
"Nerdbank.Streams": "2.10.69",
"Newtonsoft.Json": "13.0.3",
"OmniSharp.Extensions.JsonRpc.Generators": "0.19.9",
"System.Collections.Immutable": "5.0.0",
"System.Reactive": "6.0.0",
"System.Threading.Channels": "6.0.0"
}
So we wouldn't be able to remove the assembly due to that entrenched dependency.
Also, doing a sigcheck looks like the DLL itself hasn't changed in PSES from 2024.2.0 from 2024.3.2, so was this just a new detection that was a previous mis-signing?
As i can confirm, the former version 2024.2.0 and the pre-release version 2024.3.2 have the false and untrusted 'ameroot' certificate.
The DLL's of Hotfix Version 2024.2.1 are signed correctly, except that one DLL "System.Reactive.DLL" - but in version 2024.0.0 the DLL works with publisher rule in AppLocker. So the best would be if the System.Reactive.DLL in 2024.2.1 has the same signing as in 2024.0.0 where it works perfectly - ideally it's the same DLL because of no code change inside the DLL?
The Reactive DLL hasn't changed but it may have been being incorrectly signed as Microsoft First Party when it is in fact Microsoft Community, that was my main query to @andyleejordan that may have been "fixed" but now breaks the ability for the extension to be wholly "pre-signed" on windows systems.
This is more of a legal issue than a technical one, so I have to defer to Andy as to whether that DLL can continue to be signed as it was before since it hasn't changed, but future versions may still have the problem anyways. I imagine this may be a change in policy as supply-chain attacks such as Solarwinds, xz, etc. have probably made Microsoft extremely sensitive about these sorts of things.
You've written it out exactly Justin. When switching to the new signing system, it detected that System.Reactive.dll is Microsoft Community and signed as such, and wouldn't let me sign it as first-party Microsoft Corporation. It was an error that it was previously, and allowed by a system that I no longer have access to. However, all the OmniSharp DLLs etc. are being signed with the same certificate, so I'm not sure why AppLocker is having an issue with this one and not those? We've never published exclusively first-party DLLs because of those dependencies.
This issue has been labeled as resolved, please verify the provided fix (or other reason).