New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for Enterprise signed scripts #21550
Comments
Just to expand on this, they do still work it's just that PowerShell prompts whether you trust the new publisher or not.
A few questions
Personally I would not be a fan of having to opt into allowing this check. I would find that it adds a barrier to entry for using these types of certificates and punishes developers for trying to sign their code which is not something we would want to encourage. Instead if there is a desire to have a way to use the existing behaviour maybe that should be opt in rather than the new ay being opt in? |
The opt-in is necessary as PowerShell would need to know the EKU to check against. If you're concerned about new execution policies, then an alternate option is that if the reg property exists, then PowerShell would run
|
Sorry if I wasn't clear, this was more of a way to improve the UX of running an untrusted publisher for the first time. Right now if PowerShell is set to run a signed script with a publisher that is unknown it will prompt you if you wish to trust it. If you do it will add that cert to the
The question was whether this new check should be a new policy or a new behaviour for the existing policies.
While I cannot say how PSResourceGet implemented things I know the PowerShellGet
It sounds like the opt-in is should be populating the registry value rather than opt-ing into checking for the registry value in the first place. My concern is that I publish a module that's signed by Azure TS (or even my own internal mechanism) and users who want to verify the signature now need to explicitly trust my EKU rather than today where PowerShell will at least prompt whether you trust it or not. As mentioned earlier it is also possible for non-admin users to trust a publisher. One other area I haven't looked into too closely is how do revocations work with certs. Should PowerShell offer the ability to revoke a specific EKU. Does the normal authenticode signature check done by Windows take into account revoked certificates, etc. |
Ok, now I see what you are asking. Yes, it makes sense to improve the prompt but the user would need to be elevated to populate the registry.
I believe the question was answered?
Since PSResourceGet calls out to
Authenticode (which we call the WinTrust APIs) should automatically take care of cert revocation. |
To be clear I'm suggesting that instead of adding two completely new policies you either just add this new EKU registry checking behaviour by default with no opt in or out option or add in an opt out option instead of having people explicitly have to use a new policy. This would be in lieu of explicit execution policies to control things.
To revoke a single cert, what happens if you want to distrust a specific publisher altogether. You would have to find every single cert they used to sign and add them to get that to work. |
@jborean93 I see. So the fact that the registry property exists would be an indicator that the user has opted into the change in behavior. That seems reasonable to me.
Need to think more about revocation. |
It seems like PowerShell just relies on the current system for cert revocation: https://learn.microsoft.com/en-us/azure/trusted-signing/how-to-cert-revocation This means that customers can either revoke individual certs (yes, can be laborious), or revoke all the certs.
|
Summary of the new feature / enhancement
[Updated based on feedback below]
Azure has a new Trusted Signing service in public preview. One of the features is rotation of the signing cert. This breaks how PowerShell currently validates signed scripts.
PowerShell only trusts the leaf cert in the chain and this cert will be rotated (by Azure or any other cert service). So a customer may initially sign a script and it works, but then after the cert is rotated new scripts won't work since the leaf cert has changed and old certs might have expired so old scripts also stop working in an execution policy that requires signing.
Proposed technical implementation details (optional)
Azure Trust Signing customer signing cert has a customer unique EKU. We would allow storing additional signing metadata in the registry:
HKLM\Software\Microsoft\PowerShellCore\TrustedEnterpriseEKU
as a string array representing the customer unique EKUs1.3.6.1.4.1.311.97.990309390.766961637.194916062.941502583
Existing
AllSigned
andRemoteSigned
execution policies will respect the EKU if it has been stored in the registry (this is how the customer opts into this change in behavior):Get-Authenticode
), if valid then:TrustedEnterpriseEKU
as stored in the registryThis would allow for alternate signing services to also participate and work with PowerShell.
Cert revocation will continued to be handled by WinTrust and no change for PowerShell.
The text was updated successfully, but these errors were encountered: